Multics Technical Bulletin MTB-685-01
V5 Message Segments
To: Distribution
From: Benson I. Margulies
Date: 11/12/84
Subject: Version 5 Message Segments
1 ABSTRACT
The message segment primitives do not store enough
information about the senders of messages to permit
some privileged servers to completely authenticate
these requests. Version 5 message segments add the
sender process id and maximum authorization to the
message segment to support the volume retriever and the
AS request mechanism. Revision 01 of this MTB, |
carrying change bars, adds the sending process' audit |
flags to the message. This was an oversight of the |
original. |
Comments should be sent to the author:
via Multics Mail:
Margulies at either System-M, MIT, or CISL-SERVICE.
via Forum:
>udd>m>mtgs>B2 on System-M
via telephone:
(HVN) 261-9333, or
(617) 492-9333
_________________________________________________________________
Multics project internal working documentation. Not to be
reproduced or distributed outside the Multics project without the
consent of the author or the author's management.
MTB-685-01 Multics Technical Bulletin
V5 Message Segments
2 WHY SERVERS NEED MORE DATA ABOUT THE SENDER
A privileged server must make an interpretive access control
decision on behalf of the user process that requested the
service. Some system access control policies are defined to
include a check of the maximum authorization of the user. The
message segment primitives do not store a secure maximum
authorization in the message, thus a privileged server cannot
enforce those access control policies.
Appending a multi-class segment (or upgraded directory) is such
an operation. The volume retriever must append on behalf of the
submitter of the retrieval request. Thus, it must know the
submitter's maximum authorization.
The Answering Service Request mechanism uses a message segment to
queue requests from users. Most of these requests apply to a
particular process, rather than to a named user. In the absence
of a process id maintained by the message segment primitives,
as_request_server_ depends on the process id supplied in an IPC
wakeup sent by the submitter. Coordinating the wakeup's and the
messages cannot be done perfectly reliably, though, and so lost
wakeups and other incidents can disrupt the protocol.
Furthermore, as_request_server_ must complete each request when
received, because it has no place to store the process id when
serving a delayed request.
3 VERSION 5 MESSAGE SEGMENTS
To resolve the problems described above, a the version
number of the standard message segment will be advanced from 4 to
5. The standard message segment auto-conversion strategy will be
used. All queue message segments and mailboxes will be converted
to version 5 the first time that they are referenced.
The version 5 message segment will store three new fields
| with each message: the sender max authorization, the sender
| process id, and the sender process audit flags.
Since messages will be longer, it is possible that a very
full message segment or mailbox would fail to fit into a segment.
The standard message segment conversion stragety discards the
messages at the end of the segment in this case as a result of a
salvage. In past conversions no special provisions have been
made for finding such segments or avoiding such data loss. The
design philosophy is this: We document no reliable, repeatable
way to determine how much stuff will fit into a mailbox. Thus,
users should not depend on the exact capacity. The SRB notice
Multics Technical Bulletin MTB-685-01
V5 Message Segments
will point out that the new format consumes 4 extra words per
message in the segment.
4 NEW CALLING SEQUENCES
There is no space in the mseg_return_args structure for a
max authorization, and no version number. Since there are many
callers of the existing read entrypoints, we will create new read
entrypoints that use a new structure. In addition to a version
number, the new structure encodes the various options for reading
a message that are currently encoded by a multitude of
entrypoints.
The new entrypoints are:
XXXX_$read_message_index
XXXX_$read_message_file
Where XXXX is either message_segment_ or mailbox_. The calling
sequences follow:
declare XXX_$read_message_index
entry (fixed bin, pointer, pointer, fixed bin (35));
declare XXX_$read_message_file
entry (char (*), char (*), pointer, pointer, fixed bin (35));
call XXX_$read_message_index (index, area_ptr, info_ptr, code);
call XXX_$read_message_file (dn, en, area_ptr, info_ptr, code);
Where:
index is a mailbox/message segment opening index. (input)
dn is the directory name of the mailbox/message segment. (input)
en is the entry name of the mailbox/message segment. It must end
with the .mbx/.ms suffix. (input)
area_ptr is a pointer to an area in which the message text will
be allocated. (input)
info_ptr is a pointer to a caller-allocated mseg_message_info
structure, as described below (input, but some fields
in structure are output).
code is a standard system status code (output).
MTB-685-01 Multics Technical Bulletin
V5 Message Segments
dcl mseg_message_info_ptr pointer;
dcl 1 mseg_message_info based
(mseg_message_info_ptr) aligned,
2 version char (8) aligned,
2 message_code fixed bin,
2 control_flags unaligned,
3 own bit (1),
3 delete bit (1),
3 pad bit (34),
2 ms_ptr ptr,
2 ms_len fixed bin (24),
2 ms_id bit (72),
2 ms_access_class bit (72),
2 sender_id char (32) unaligned,
2 sender_process_id bit (36) aligned,
2 sender_level fixed bin,
2 sender_authorization bit (72),
2 sender_max_authorization bit (72),
| 2 sender_audit bit (36);
declare MSEG_MESSAGE_INFO_V1
char (8) aligned init ("msegmi01")
int static options (constant);
declare (
MSEG_READ_FIRST init (1),
MSEG_READ_LAST init (2),
MSEG_READ_SPECIFIED init (3),
MSEG_READ_BEFORE_SPECIFIED init (4),
MSEG_READ_AFTER_SPECIFIED init (5))
fixed bin int static options (constant);
declare (
MSEG_READ_OWN init ("1"b),
MSEG_READ_DELETE init ("01"b)
) bit (36)
aligned internal static options (constant);
Where:
version Is the version of this structure. The caller must set
this to MSEG_MESSAGE_INFO_v1.
message_code specifies which message is to be read from the
message segment. This value must be set by the caller
to one of the following named constants:
MSEG_READ_FIRST to read the first message.
MSEG_READ_LAST to read the last message.
MSEG_READ_SPECIFIED to read the message specified by
Multics Technical Bulletin MTB-685-01
V5 Message Segments
mseg_message_info.ms_id.
MSEG_READ_BEFORE_SPECIFIED to read the message previous
to the message specified by mseg_message_info.ms_id.
MSEG_READ_AFTER_SPECIFIED to read the next message
after the message specified by mseg_message_info.ms_id.
own is a flag. If set to "1"b, only messages added to the
segment by the calling user will be returned. This
must be set by the caller.
delete is a flag. If set to "1"b, the message will be deleted
after it is read out. This must be set by the caller.
ms_ptr is a pointer to the message read from the message segment.
This pointer is meaningful if and only if code is
returned 0. The message always begins on a double-word
boundary.
ms_len is the length of the message, in bits.
ms_id is a message segment/mailbox message id. If the
message_code is MSEG_READ_SPECIFIED,
MSEG_READ_BEFORE_SPECIFIED, or
MSEG_READ_AFTER_SPECIFIED, this is interpreted on
input, and must be the message id of a message in the
message segment to which the caller has access. On
output, it is the message id of the returned message.
ms_access_class is the access class of the message returned.
sender_id is the process group id of the process that added the
message to the segment.
sender_process_id is the process id of the process that added the
message to the segment. It may be zero to indicate
that no process id is available.
sender_level is the validation level of the process that added
the message to the segment.
sender_authorization is the authorization, including privileges,
of the process that added the message to the message
segment.
sender_max_authorization is the max authorization of the process
that added the message to the message segment.
sender_audit are the audit flags for the process sending the |
message. |
MTB-685-01 Multics Technical Bulletin
V5 Message Segments
5 QUEUE_ADMIN_
The entrypoints in queue_admin_ currently accept mseg_return_args
to specify the characteristics of the message to be added. They
will be changed incompatabily to accept mseg_message_info. There
are only three callers to be converted.
6 DELETE V2 AND V3 MESSAGE SEGMENT SUPPORT.
At this time we will remove the conversion code for version 2 and
3 message segments. Any message segment untouched since July of
1977 will be useless.
7 TESTING PLANS
All gate interfaces to the message segment and mailbox gates will
be exercised using a command interface to the gates written by
the B2 evaluation team.