Multics Technical Bulletin                                MTB-684
Bump request

To:       Distribution

From:     R. Michael Tague

Date:     10/09/84

Subject:  Answering Service Bump Request


     This MTB describes the changes to the Answering Service
     required to  allow privileged system  processes such as
     the Data Management Daemon to bump user's processes.

     This feature  is needed by  Data Management so  that DM
     Daemons can bump users who refuse or are unable to exit
     a  Daemon's DM  system.  This is  not intended  to be a
     general user bumping user facility, but is intended for
     the use of privleged system processes.

Comments should be sent to the author:

via Forum:

via Multics Mail:
   Tague.Multics on either System M or MIT Multics.

via telephone:
   HVN (617) 492-9358


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.

Multics Technical Bulletin                                MTB-684
Bump request


In  order  to  obtain  quick  startups  of  Data  Management (DM)
systems, it is desirable for  each Data Management system to have
a shutdown  phase where that  Data Management system  will become

During this phase the Data  Management Daemon associated with the
DM system in  shutdown must take actions to  remove any user from
the DM  system who refuses  or is unable  to exit the  DM system.
The prefered  way of accomplishing  this is for the  DM Daemon to
prevent further  access to the  DM system and  to forceably adopt
uncommited  transactions and  roll them  back.  Unfortunatly this
method would  require more time to  implement than can reasonably
be spent on  this task prior to MR11.   Hence we are implementing
an  alternative  mechanism  where  the  DM  Daemon  requests  the
Answering  Service  to  bump  the  offending  user  from  Multics
allowing  the  Daemon  to adopt  uncommited  transactions through
already established methods.


3.1 Overview

A process wishing to logout another process will send a bump user
request  to  the Answering  Service  via the  Answering Service's
request  channel.  The  request will consist  of a  process id, a
message, and a grace period.  The message will be sent as a blast
message to the  terminal of the process specified  by the process
id  at the  time the  request is  made if  the process  is not an
absentee.  The  specified grace period of  time after the request
is made and  the message sent, the Answering  Service will remove
this process from the system.

All requests made by any  process to bump another process whether
successful  or  not  are logged  in  the system  log.   There are
various access checks made by  the Answering Service to establish
that the requesting process is  authorized to bump users and that
the  requested action  will not be  in violation  of our Security

Finally,  the requesting  process can establish  an event channel
for the Answering  Service to reply upon.  If  a reply channel is
supplied, the reply will be a  code and a reference id.  The code
is a standard system error code intended to report the success or
failure of the  bump request.  The reference id  is the reference
id  that  the requestor  suppled  with the  bump request.   It is
expected that the reference id will be equal to the process id of

MTB-684                                Multics Technical Bulletin
                                                     Bump request

the  process  to be  bumped, but  it  does not  have to  be.  The
reference id has meaning only to the requesting process.

3.2 The User's Request

The requesting  process calls system_info_$request_chn  to obtain
the  name and  location of the  message segment that  is used for
Answering  Service requests.   The requesting  process then calls
message_segment_$add_file   with   an  appropriately   filled  in
asr_bump_user_info structure as the  message.  This structure can
be  obtained  from  the as_requests.incl.pl1  include  file.  Its
definition is:

dcl  1 asr_bump_user_info aligned based (asr_bump_user_info_ptr),
       2 header aligned like as_request_header,
       2 version char (8),
       2 process_id bit (36),
       2 message char (100) unaligned,
       2 grace_time_in_seconds fixed bin,
       2 reply_reference_id bit (36);

     header is the like as_request_header.incl.pl1 defined below.

     version  is  the  structure   version.   Currently  set  to:

     process_id is  the process_id of  the process that  is to be

     message is  a message to be  sent in a blast  message to the
     terminal of the user to be bumped.

     grace_time_in_seconds  is  the  period of  time  measured in
     seconds that  the Answering Service should  wait between the
     time  the bump  is requested and  the time that  the user is
     removed from the system.

     reply_reference_id is a bit string supplied by the requestor
     that will be returned by  the Answering Service on the given
     reply channel when the bump request has been accepted.

The as_request_header.incl.pl1 structure is defined as follows:

dcl  1 as_request_header based aligned,
       2 version fixed bin,
       2 type fixed bin,
       2 reply_channel fixed bin (71);

Multics Technical Bulletin                                MTB-684
Bump request

     version   is   the  header   version.   Currently   set  to:

     type  is the  request type.   The following  types have been
     declared as constants in the include file:

        ASR_DIAL_SERVER or dial_server_type
        ASR_DIAL_OUT or dial_out_type

     reply_channel  is  the  event  channel  that  the  Answering
     Service is  to return an  error code and  reference id upon.
     If zero, no reply is sent.

Once the  structure has been  filled in and added  to the message
segement,  the  requesting  process   sends  a  wakeup  over  the
Answering Service's request channel.

3.3 Answering Service Action

When the  Answering Service receives the  wakeup it retrieves the
structure from the message segment  and based on the type defined
in  the as_request_header,  it passes control  to the appropriate
routine  to handle  the request.   For the  ASR_BUMP_USER request
type this routine is as_request_bump_user_.

as_request_bump_user_  validates  the  request  by  checking  the
requestor's access  to an ACS  segment in the  system defined ACS
directory.   That  ACS segment  is bump_user.acs.   The requestor
must  have  write access  to the  segment to  be allowed  to bump
another process.  The request is  also validated by comparing the
authorization of the requestor's process with that of the process
that  is  to  be bumped.   The  two  processes must  be  of equal
authorization.  All  attempts to bump another  user whether valid
or not are logged in the system log.

If the requestor specified a reply channel, the Answering Service
replies on  that channel with a  code and the reply_reference_id.
The code  is either zero  meaning that the bump  request has been
successfully initiated, or is set to a standard system error code
inticating that the request failed.

If  a reply  channel is  given and the  request fails  due to the
requestor not having  write access on the bump  user ACS segment,
then        the        error       code        returned       is:
error_table_$insufficient_access.  If the authorization levels do

MTB-684                                Multics Technical Bulletin
                                                     Bump request

not match,  the error code  is:  error_table_$ai_restricted.  And
if the Answering Service could not find the process that is to be
bumped, the error_table_$as_bump_user_not_found is returned.

After  the request  has been validated  and it is  found that the
requestor does have the correct  access for the bump user request
to be performed,  the Answering Service sets a  wakeup for itself
at grace_time_in_seconds  in the future, sends  the given message
to the  process to be bumped  as a blast message,  and replies to
the requestor if a reply channel was given.

When  the wakeup  goes off  the the  Answering Service  bumps the
target  process   from  the  system  using   the  normal  bumping

3.4 Security Policy Implications

Because  this  subsystem operates  from within  the initializer's
process  and  performs privlleged  actions  at the  request  of a
user's  process,  its  actions  must be  scrutinized  closely for
potential violations of security policy.

While  it is  expected and intended  that the  bump user facility
will  only be  used by system  processes, it is  not expected nor
should it be  required that these process be  part of the Trusted
Computing Base (TCB).  Hence this  subsystem must check to insure
that the  security policy is  not violated.  As  mentioned in the
previous section as_request_bump_user_ compares the authorization
of the process that is to be bumped with the authorization of the
process that  requested the action.   The two process  must be of
equal authorization or the action will not be allowed.

All bump user requests are logged whether successful or not.