Multics Technical Bulletin                             MTB-685-01
  V5 Message Segments

  To:       Distribution

  From:     Benson I. Margulies

  Date:     11/12/84

  Subject:  Version 5 Message Segments


       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


  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.


       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.


       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

  The new entrypoints are:


  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);


  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),
     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);


  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_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

  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

  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


  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.


  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.


  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.