Multics Technical Bulletin MTB-684
Bump request
To: Distribution
From: R. Michael Tague
Date: 10/09/84
Subject: Answering Service Bump Request
1 ABSTRACT
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:
>udd>Multics>meetings>B2_Security_Design.
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
2 INTRODUCTION
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
quiescent.
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 PROPOSED MECHANISM
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
policy.
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);
Where:
header is the like as_request_header.incl.pl1 defined below.
version is the structure version. Currently set to:
as_request_bump_user_info_version_1
process_id is the process_id of the process that is to be
bumped.
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
Where:
version is the header version. Currently set to:
as_request_version_1
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
ASR_FPE_CAUSES_LOGOUT
ASR_FPE_CAUSES_NEW_PROC
ASR_PROC_TERM_NOTIFY
ASR_BUMP_USER
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
mechanism.
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.