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.