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.