MULTICS TECHNICAL BULLETIN MTB751-03
To: MTB Distribution
From: Eric J. Swenson
Gary Dixon
Edward C. Brunelle Jr.
Date: July 15, 1987
Subject: Multics Networking Architecture Answering Service
Changes
-----------------------------------
This MTB describes proposed changes to the Answering Service to
accommodate the Multics Networking Architecture (MNA). Under the
new architecture, the responsibility of managing communications
channels is removed from the Initializer process and delegated to
a set of Login Server processes. The Initializer retains the
function of the Identification and Authentication (I&A) of user
requests to access Multics, as well as such functions as process
manipulation. This MTB documents the new and changed Initializer
process software which supports the MNA. In particular, the
Answering Service support of the Login Server processes is
described in detail.
Revision 1 corrects the description of MNA network accounting,
dialin terminals and message coordinator terminals.
Revision 2 augments the discussion of MCS Answering Service
changes to include many additional areas that were modified.
| Revision 3 adds a new access_operations_ code to Appendix B.
-----------------------------------
Comments should be sent to the author:
via Multics Mail:
GDixon at System-M.
via Forum:
>udd>DSA>mtgs>dsaimp.forum
via telephone:
(HVN) 862-3593
(602) 862-3593
_________________________________________________________________
Multics project internal documentation; not to be reproduced or
distributed outside the Multics project without permission of the
Director of MDC.
MTB751-03 MNA Answering Service Changes
CONTENTS
Page
1: Introduction . . . . . . . . . . . . . . . . . . . . 1
1.1: Current Architecture . . . . . . . . . . . . . . . 1
1.2: Problems with Current Architecture . . . . . . . . 3
1.3: Login Servers . . . . . . . . . . . . . . . . . . . 4
2: MNA Answering Service Changes . . . . . . . . . . . . 5
2.1: Login Server Requests and Responses . . . . . . . . 5
2.1.1: Login Server Requests . . . . . . . . . . . . . . 7
2.1.1.1: Validate Request . . . . . . . . . . . . . . . 7
2.1.1.1.1: Changes to the UTE . . . . . . . . . . . . . 8
2.1.1.1.2: Filling in the UTE . . . . . . . . . . . . . 9
2.1.1.1.3: Other Validation Information . . . . . . . . 9
2.1.1.1.4: uc_login_ . . . . . . . . . . . . . . . . . . 11
2.1.1.1.5: Communications Channel Access Checking (or 12
lack thereof) . . . . . . . . . . . . . . . . . . . . .
2.1.1.2: Process Request . . . . . . . . . . . . . . . . 12
2.1.1.2.1: Create Sub-Request . . . . . . . . . . . . . 13
2.1.1.2.2: uc_create_process_check_ . . . . . . . . . . 14
2.1.1.2.3: uc_create_process_ . . . . . . . . . . . . . 14
2.1.1.3: Connect Request . . . . . . . . . . . . . . . . 15
2.1.1.3.1: uc_setup_process_connect_ . . . . . . . . . . 15
2.1.1.3.2: uc_set_pit_tty_info_ . . . . . . . . . . . . 16
2.1.1.4: Destroy Request . . . . . . . . . . . . . . . . 16
2.1.1.5: New_Proc Request . . . . . . . . . . . . . . . 17
2.1.1.6: List Request . . . . . . . . . . . . . . . . . 17
2.1.1.6.1: uc_list_disconnected_procs_ . . . . . . . . . 17
2.1.1.7: Disconnect Request . . . . . . . . . . . . . . 18
2.1.1.8: Logout Request . . . . . . . . . . . . . . . . 18
2.1.1.9: Dial Request . . . . . . . . . . . . . . . . . 18
2.1.1.9.1: uc_dial_ . . . . . . . . . . . . . . . . . . 19
2.1.1.10: Operator Request . . . . . . . . . . . . . . . 19
2.1.2: Login Server Request Processing . . . . . . . . . 20
2.2: Process Termination Handler . . . . . . . . . . . . 21
2.2.1: Fatal Process Error Wakeups . . . . . . . . . . . 22
2.2.2: New_Proc Wakeups . . . . . . . . . . . . . . . . 23
2.2.3: Logout Wakeups . . . . . . . . . . . . . . . . . 23
2.2.4: Hangup Wakeup . . . . . . . . . . . . . . . . . . 23
2.2.5: Bump, Shutdown, Terminate, Detach Wakeups . . . . 23
2.2.6: Unbump Wakeup . . . . . . . . . . . . . . . . . . 24
2.2.7: Handling of Destroy and New_Proc Preaccess 24
Requests . . . . . . . . . . . . . . . . . . . . . . . .
MNA Answering Service Changes MTB751-03
CONTENTS (cont)
Page
2.2.8: Other Wakeups . . . . . . . . . . . . . . . . . . 24
2.2.9: The Process Termination Cycle . . . . . . . . . . 24
2.2.9.1: User-Initiated Process Terminations . . . . . . 24
2.2.9.2: System-Initiated Process Terminations . . . . . 25
2.2.9.3: Cleanup of Network Connections . . . . . . . . 26
3: Changes to MCS Answering Service Modules . . . . . . 27
3.1: User Table Changes . . . . . . . . . . . . . . . . 27
3.2: dpg_ . . . . . . . . . . . . . . . . . . . . . . . 27
3.3: dial_ctl_ . . . . . . . . . . . . . . . . . . . . . 27
3.4: daemon_user_manager_, absentee_user_manager_, 28
ftp_dialup_, and dialup_ . . . . . . . . . . . . . . . .
3.5: as_access_audit_, access_operations_, dial_ctl_ and 28
lg_ctl_ . . . . . . . . . . . . . . . . . . . . . . . .
3.6: convert_access_class_ . . . . . . . . . . . . . . . 29
3.7: User Message Facility . . . . . . . . . . . . . . . 29
3.8: login_server_overseer_$test . . . . . . . . . . . . 29
3.9: test_system_control, run_test_as . . . . . . . . . 29
3.10: as_init_ . . . . . . . . . . . . . . . . . . . . . 30
3.11: act_ctl_ and load_ctl_ . . . . . . . . . . . . . . 30
3.12: as_data_ . . . . . . . . . . . . . . . . . . . . . 31
3.13: asu_ . . . . . . . . . . . . . . . . . . . . . . . 31
3.14: as_check_condition_ . . . . . . . . . . . . . . . . 31
3.15: multics_libraries_ . . . . . . . . . . . . . . . . 32
Appendix A: Subroutine Documentation . . . . . . . . . . 33
convert_access_class_ . . . . . . . . . . . . . . . . 34
Appendix B: System Administration Procedures . . . . . . 35
Identification and Authentication (I&A) . . . . . . . 35
Process Manipulation . . . . . . . . . . . . . . . . . 39
Communications Channel . . . . . . . . . . . . . . . . 40
Audit Message Format for Communications Channel 40
Attachment . . . . . . . . . . . . . . . . . . . .
Table B-1: access_operations_.alm . . . . . . . . . . 43
Appendix C: Privileged Interfaces MTB . . . . . . . . . 44
login_server_overseer_$test . . . . . . . . . . . . . 45
run_test_as . . . . . . . . . . . . . . . . . . . . . 46
test_system_control . . . . . . . . . . . . . . . . . 47
MNA Answering Service Changes MTB751-03
111::: IIINNNTTTRRROOODDDUUUCCCTTTIIIOOONNN
This MTB is part of a set which documents the Multics Networking
Architecture (MNA) and the changes to Multics software required
to support this new architecture. The reader is referred to
MTB-748 for a general overview of the networking architecture and
is assumed to be familiar with its contents. This MTB details
the proposed changes to the Answering Service software to
accommodate the MNA. Under this architecture, the Answering
Service software (which runs in the Initializer process) would no
longer have the responsibility of managing the communications
channels over which logins, dials, dial-outs, and ftp requests
occur. The motivation for this change is many-fold and discussed
in a following section.
The role of "communications channel management" shifts from the
Answering Service to inner-ring TCB software as well as user-ring
Login Server software. Under the new architecture, inner-ring
TCB software manages outbound communications channel connections,
such as dial-outs, while Login Servers, and the body of software
executed by these processes, manage the inbound connections to
Multics. The inner-ring TCB software is described in other MTBs
and is not particularly relevant to the topic of this MTB.
However, the Login Server software must interface with the
Answering Service in order to "identify and authenticate" user
requests for Multics service and to initiate those services. A
later section of this MTB describes the Login Server operation in
brief; the reader is referred to MTB-752 for details. The
operation of the Answering Service support for Login Servers is
described in considerable depth in this MTB.
While the MNA defines the direction Multics communications
software should take in the future, and provides the framework
for the Distributed Systems Architecture (DSA) implementation on
Multics for MR12, it is not clear if, and when, the Multics
Communications System (MCS) might be converted to comply with
this new architecture. For MR12, only DSA will be made to
conform to MNA. It should be kept in mind, however, that the
architecture is intended to be generalized and DSA is only one of
its clients. There is no, or should be no, knowledge of DSA
within the body of software which implements MNA.
Before proceeding with a description of the design of the
Answering Service changes, a brief description of the motivation
for the changes follows a short description of the current,
i.e. pre-MR12 architecture.
111...111::: CCCuuurrrrrreeennnttt AAArrrccchhhiiittteeeccctttuuurrreee
In MR11, the primary means of user access to Multics is through
communications channels connected directly or indirectly to
MTB751-03 MNA Answering Service Changes
Frontend Network Processors (FNPs). In concert with the Multics
Communications Systems (MCS), a body of software which runs both
in the FNPs and in the Multics ring-0 Trusted Computing Base
(TCB), the FNP hardware components provide asynchronous and
synchronous communications channel access to Multics. The
Answering Service, a user-ring subsystem which runs in the
Initializer process on Multics, both manages all MCS connections
and engages users in the login dialogue necessary to properly
identify and authenticate user access to the system.
A secondary interface to Multics is provided by the separately
priced TCP/IP software, which allows connections to the Defense
Data Network (DDN). The TCP/IP software, however, indirectly
uses MCS through ring-0 simulation of FNP connections. The
Software Terminal (STY) software, part of MCS, presents the
Answering Service with a communications channel interface which
is virtually indistinguishable from normal FNP channel
connections.
The Answering Service uses as one of its central databases for
managing interactive user logins (either through FNPs or STYs)
the Channel Definition Table (CDT). The present software assumes
that every interactive user has an entry in the CDT which
describes the MCS channel over which the user is logged in.
Further, any process which desires to perform a slave attachment
of a communications channel, or dial out over a communications
channel must request the Answering Service to provide the
service. This allows the Answering Service to perform access
control checks, perform access auditing, and call upon ring-0 MCS
to assign the communications channel to the user process.
All communications channels are initially assigned to the
Answering Service (Initializer process). MCS notifies the
Answering Service of any dialups or hangups on the channel, as
well as other I/O-related events. After the channel is delegated
to a user process (for instance as the primary login channel for
the user), the Answering Service retains the supervisory role for
the channel, receiving notification of the "hangup" condition.
Most other I/O-related events are signalled to the user process.
The "hangup" condition signals the Answering Service that it
should unassign the channel from the user process and perform the
necessary access auditing.
At any time, with the present architecture, the Answering
Service, by virtue of its supervisory communications channel
status, may write directly on any channel. This mechanism is
used not only during the login dialogue (to prompt the user and
read responses, for example) but also to implement the operator
"warn" command, the messages associated with the "bump" command,
and other instances of "channel blasting", such as notification
of other login instances.
MNA Answering Service Changes MTB751-03
111...222::: PPPrrrooobbbllleeemmmsss wwwiiittthhh CCCuuurrrrrreeennnttt AAArrrccchhhiiittteeeccctttuuurrreee
While the current architecture suffices for FNP channels, a
certain amount of overhead is incurred for STY channel
processing, where the I/O from the TCP/IP network undergoes
multiple copying before it reaches the user process, involves the
cooperation of two processes, and relies upon ring-0
intervention. One particular deficiency in the use of STYs to
handle TCP/IP connections is the use of ring-0 table and buffer
space in order to accommodate the connections. Table and buffer
space is already required for each TCP/IP connection within the
TCP/IP subsystem, so in essence, the ring-0 space is wasted. On
the other hand, the STY mechanism required only minimal changes
to the Answering Service to support because TCP/IP connections
appear to the Answering Service as normal MCS connections.
As previously mentioned, the operation of the Answering Service
is tied to the CDT for interactive users. This table contains
entries for all MCS channels known to Multics. While this kind
of architecture is appropriate for the static nature of physical
FNP channels, it is not dynamic enough to accommodate network
connections. The use of STY channels for TCP/IP connections to
Multics makes up, to a degree, for the static nature of the CDT,
however enough STY channels must be configured to accommodate the
maximum number of simultaneous TCP/IP connections expected. Each
configured STY channel requires some amount of dedicated
table/buffer space in both the ring-0 MCS database and in the
ring-4 CDT.
Perhaps more significant a problem than reduced efficiency and
wasted space through use of STY channels, is the workload on the
Initializer process required to manage all the MCS channels.
Associated with each MCS-defined channel is an Inter-Process
Communication (IPC) "event channel." Two Answering Service
modules (dialup_ for normal interactive channels, and ftp_dialup_
for File Transfer Protocol, or FTP, TCP/IP channels) are the
event handlers for wakeups associated with the respective MCS
channels. When an MCS channel dials up or hangs up, one of these
programs is invoked. Each wakeup associated with the
interactions during the login dialogue causes the invocation of
these programs.
There are many subsystems within the Initializer process which
are event-driven and, as such, the response time of the login
dialogue degrades as the Initializer is burdened with more and
more activities. By the same token, the performance of other
event-driven subsystems suffers as the Answering Service handles
the login dialogue.
In supporting the MNA, and in particular the Distributed Systems
Architecture (DSA), Multics will have to handle an arbitrary and
dynamic number of incoming network connections. Some of these
MTB751-03 MNA Answering Service Changes
connections will request "login" service, others, various other
services, including "file transfer" service. Rather than adding
to the burden of the Initializer process by using the STY
approach, as in the case of the TCP/IP network support, an
alternative approach is desired. Apart from the security-issues
associated with access to particular communications channels,
there is no inherent reason why the Initializer process is
required to manage all communications channels. Further, there
is no reason for the Answering Service to have to manage the
login dialogue. It is only required to perform the actual
Identification and Authentication (I&A) and to provide the
requested services. The MNA proposes to extract the
communications channel management and preaccess dialogue
functions from the Answering Service and call upon Login Server
processes to perform these functions. A protocol for requesting
I&A and services from the Answering Service is established and
documented in this MTB.
111...333::: LLLooogggiiinnn SSSeeerrrvvveeerrrsss
The Multics Networking Architecture calls for Login Server
processes to listen for requests for communications channel
access to Multics over specified endpoints. Endpoints are
defined for various services, such as "login" or "file transfer"
and are network-specific. Inbound requests-for-services are
negotiated by the login server via a login dialogue or some
agreed-upon protocol and then validated by the Answering Service.
Then, in cooperation with the Answering Service, the requested
service is started. This service may involve process
manipulation (i.e. process creation, connection, etc.), may
result in "dialing" a process, or could involve the establishment
of a message coordinator terminal. These services are all
described in the next section.
Once the requested service is initiated, the login server gives
control of the communications channel to the appropriate process
and awaits notification by the Answering Service of process
termination or from the underlying network software of a network
channel disconnection (hangup). In the case of hangups, the
Answering Service is notified by the login server so that it may
perform the necessary cleanup (usually process logout or
disconnection).
The login server processes (there may be several handling
different networks or different services) are semi-privileged
daemons. They require whatever access is necessary to interact
with the underlying network software. Further, they require
special access to communicate with the Answering Service.
Through these daemons, the burden of the login dialogue and the
managing of communications channels over the supported network
interfaces is removed from the Initializer process while the
MNA Answering Service Changes MTB751-03
security-critical services of User Control (I&A, process
manipulation, etc.) remain centralized, there, for auditing and
accountability purposes. The rest of this MTB describes the
changes to existing Answering Service software, and the new
software needed to support the login servers.
222::: MMMNNNAAA AAANNNSSSWWWEEERRRIIINNNGGG SSSEEERRRVVVIIICCCEEE CCCHHHAAANNNGGGEEESSS
The MNA answering service changes consist primarily of providing
an interface for interactions between the login server processes
and the answering service. These interactions take the form of
"login server requests" and "answering service responses."
Unfortunately for terminology's sake, we have introduced several
misnomers into the vocabulary, since there are instances where
the answering service must communicate with the login servers
independent of any "login server request" and these interactions
are also referred to as "responses". This MTB attempts to play
down this bad naming convention, although the include files which
describe the data structures involved will undoubtedly perplex
the reader -- hence the warning.
In addition to a mechanism for login server/answering service
communication, the various software components which are involved
in identification and authentication, process manipulation,
process termination handling etc. -- henceforth referred to as
"user control software" -- are modified or replaced so as to not
be inextricably wed to the Channel Definition Table (CDT) and to
be able to cognizant of the existence of login servers, where
necessary. Various other components of user control are so
difficult to maintain at present, that they were completely
replaced by new modules which handle the MNA connections.
222...111::: LLLooogggiiinnn SSSeeerrrvvveeerrr RRReeeqqquuueeessstttsss aaannnddd RRReeessspppooonnnssseeesss
A new event-driven subsystem, the "login server request server,"
is added to the Answering Service to process login server
requests. While the function of the new server parallels that of
the so-called "AS request server", the security-critical nature
of the login server communications (such as the need to transmit
passwords to the answering service) and the desire to minimize
contention on the request queue suggest the use of a separate
request queue and server.
The new module ls_request_server_ implements the driver for the
new server. Its $init entrypoint is called by the
login_request_server command and establishes
>sc1>login_server_requests.ms as the repository for requests and
establishes an event channel for notifying the answering service
of requests to process. The ACL on the message segment should
only allow messages to be added by the login server processes,
MTB751-03 MNA Answering Service Changes
which should be registered on the Daemon project. This ACL
should be considered highly sensitive, for any process that can
submit login server requests can cause new and active processes
to be manipulated. The system_start_up.ec (in part 3) should
give the login server project "ao" access to the request queue.
The event channel is published in the answer_table, requiring
that login servers be given access to this table. The event
channel is a "call channel" and the module
uc_ls_rq_server_wakeup_ is the handler for any wakeups sent over
the channel.
Login servers initiate requests by allocating and filling in a
structure and calling the new module send_ls_request_ to send the
request to the Answering Service and wait for a response.
send_ls_request_ determines the event channel and process_id of
the Answering Service, as well as the location of the request
message segment by calling login_server_info_$request_info.
send_ls_request_ then adds a request (message) to the message
segment and sends a wakeup to the answering service. It goes
blocked awaiting a response from the answering service.
The new answering service routine uc_send_ls_response_ is called
by various answering service programs to respond to a Login
Server request. The response a combination of an IPC wakeup with
associated event message; and an optional User Message facility
data entry. The IPC message contains various flags and an error
code and indicates to the login server whether a User Message has
been sent. These flags and error code are returned to the caller
of send_ls_request_. No handling of the User Message is
performed by send_ls_request_; it is the caller's (login
server's) responsibility to extract the message from the User
Message database.
Responses to the Login Server occur only for user validation,
process creation, process connection or process termination
operations. If uc_send_ls_response_ receives an error when
sending the response (wakeup to the Login Server event channel),
it assumes that the Login Server process has been destroyed.
Because none of these operations can complete without cooperation
of the Login Server, it is best to disconnect the terminal when
sending the response fails. Therefore, uc_send_ls_response_
calls the force_disconnect entrypoint specified for the
connection in the active connection list to tell the MNA
correspondent (eg DSA) to disconnect the terminal.
Similarly, if the MNA correspondent fails in sending the login
server a wakeup (eg, when the user disconnects the terminal),
then the correspondent sends a disconnect request directly to the
Initializer process to cause proper disconnection of terminal
from the process.
MNA Answering Service Changes MTB751-03
The next section describes the operation of each of the defined
login server requests. MTB-752 provides detailed documentation
of the data structures which embody the login server requests and
responses. This MTB refrains from duplicating this information.
The user is referred to MTB-752 for the layout and content of
these requests and responses.
2.1.1: LOGIN SERVER REQUESTS
There are seven types of login server requests currently defined
and declared in the include file login_server_messages.incl.pl1.
They are the "validate," "process," "list," "dial," "disconnect,"
"logout," and "operator" requests. Each is described in its own
section. Associated with all login server requests are version
numbers and request types. Additionally, an event channel
provides the Answering Service with the means to reply to the
login server, and a handle (manufactured by the login server) is
used by both processes to distinguish the connection for which
the requests and responses apply. The handle is also used by
both the Answering Service and the Login Server to identify the
User Message which may be optionally sent with IPC responses.
2.1.1.1: Validate Request
The validate request is used to identify and authenticate a user
request for access to the system. This request is used for
normal user logins which may result in process manipulation, dial
use, or message coordinator use. The type of service, however,
is not specified in the validate request itself, but is implicit
in a request which follows the validate request. The module
which implements the validate request is uc_ls_validate_request_.
Note that the distinction between user validation (i.e. ensuring
the validity of the supplied user id, project id, password, AIM
authorization, etc.) and process creation is made very clear in
the MNA answering service -- in fact these two functions are
performed via different login server requests and are not as
tightly coupled as in the normal answering service. Thus, for
instance, the checking of the value of the "-ring" control
argument on the login command line, which makes no sense for dial
or message coordinator logins does not occur through the validate
request, but occurs as a result of a "process" request, described
later.
For every validate request, the Answering Service allocates a
User Table Entry (UTE). Thus, a change from the MCS Answering
Service, dial and message coordinator users have UTEs associated
with them. UTEs are allocated in the answer_table, since all MNA
connections through login servers are assumed to be interactive
processes. In fact, MNA connections may be created (from outside
MTB751-03 MNA Answering Service Changes
Multics) as a result of batch or RJE use; the MNA Answering
Service does not handle these specially.
2.1.1.1.1: Changes to the UTE
In order to accommodate MNA, the UTE was expanded to include
several more variables. In addition, the UTE structure was
reorganized to more logically group elements.
The new UTE variable "process_type" defines whether the user is
interactive, absentee, or a daemon user. Many answering service
modules attempted to determine this using various heuristics, and
it seemed simpler to add this variable to the UTE, have it
calculated only one time, and then used repeatedly.
Two new flags were inserted in a former pad field:
"user_specified_immediate" flag indicates whether or not the user
specified the "-immediate" control argument on a pre-access
command line (for MCS, this is stored in the CDT, which, of
course, does not exist for MNA connections);
"user_specified_operator" reflects if the "-operator" control
argument was used, indicative of the fact that the user wished to
be logged in as an operator and have his terminal converted to a
message coordinator terminal.
Several variables describing the terminal connection were added
to the UTE. The "terminal_type", "line_type" and "tty_id_code"
are stored in the UTE because they are used by various parts of
the answering service (for MCS connections, they were available
in the CDT entry). For DSA connections, the line_type is set to
LINE_DSA, a constant added to line_types.incl.pl1.
Also, a "network_connection_type" variable was added. Provided
by the login server, it reflects what kind of network connection
is being used (eg, login or file transfer). Its use is described
later on.
Finally, a set of variables associated with the login server are
added to the UTE. These variables are in the level-2 structure
login_server_info included below:
2 login_server_info,
3 our_handle bit (72) aligned,
3 his_handle bit (72) aligned,
3 termination_event_channel fixed bin (71),
3 response_event_channel fixed bin (71),
3 process_id bit (36) aligned,
"our_handle" is an identifier constructed by the answering
service and used by the login server which identifies the UTE
associated with a login server request. UTE handles are
MNA Answering Service Changes MTB751-03
fabricated by encoding the UTE index, the process type, and a
unique identifier (based on the clock) into a bit (72) value.
The process type is required in order to determine the user table
in which to locate the UTE (answer_table, absentee_user_table, or
daemon_user_table). Since MNA involves only interactive logins,
all handles created designate a process type of "interactive".
The unique identifier is required in order to handle the reuse of
UTEs correctly. The new entry asu_$setup_login_server_handle
manufactures these handles given a pointer to the UTE.
"his_handle" is an identifier constructed by the login server use
by the answering service to uniquely identify a connection being
managed by the login server. "termination_event_channel" is the
event channel over which the login server is notified when a
process terminates. "response_event_channel" is the event
channel over which the login server is notified of a response to
a login server request. "process_id" is the process id of the
login server managing a connection.
2.1.1.1.2: Filling in the UTE
After a UTE has been allocated, an event channel is established
to handle AS events associated with this connection; it is stored
in the UTE. The handler for these events is
uc_proc_term_handler_ and is described in detail below in the
"Process Termination Handler" section.
The UTE is filled in with the relevant I&A variables from the
validate request structure. The "network_connection_type"
variable, supplied by the login server process, may take on the
values declared in the include file
login_server_messages.incl.pl1. There are currently only two
values: one indicating a normal user login, the other indicating
a special login for the purposes of remote file transfer.
Processes created for the purposes of remote file transfer bear
the special instance tag "f", rather than "a" in order to
distinguish them for access control purposes. Thus, the value of
ute.tag is set to "f" or "a", as appropriate.
2.1.1.1.3: Other Validation Information
In addition to the partially filled in UTE, a second structure,
uc_validate_info, is used as a temporary repository for other
variables needed for I&A but not present in the UTE. These
variables include flags indicating whether or not to check a
password for an anonymous login ("enter" versus "enterp" logins);
the access class range of the communications channel (provided by
the login server, but for DSA always system_low:system_low);
whether to check access to the communications channel (not
currently used for MNA logins, but available if MCS is changed to
use MNA); and the encrypted password used for I&A. The
MTB751-03 MNA Answering Service Changes
uc_validate_info structure is used only for communications
between uc_ls_validate_request_ and the module which performs the
actual identification and authentication, uc_login_. It contains
both input arguments to uc_login_ as well as output arguments and
is declared below:
/* Begin include file uc_validate_info.incl.pl1 */
dcl uc_validate_info_ptr ptr automatic;
dcl 1 uc_validate_info structure aligned
based (uc_validate_info_ptr),
2 input_info,
3 channel_info,
4 access_class_range (2) bit (72),
3 password char (32) unaligned,
3 flags aligned,
4 check_channel_access bit (1) unaligned,
4 check_anonymous_password bit (1) unaligned,
4 pad1 bit (36 - 2) unaligned,
2 output_info,
3 flags aligned,
4 password_expired bit (1) unaligned,
4 password_unused_too_long bit (1) unaligned,
4 changed_password bit (1) unaligned,
4 changed_default_project bit (1) unaligned,
4 default_authorization_changed bit (1) unaligned,
4 pad2 bit (36 - 5) unaligned,
3 number_disconnected_processes fixed bin,
3 pad3 fixed bin,
3 password_interval fixed bin (71),
3 last_bad_pw_info,
4 time fixed bin (71),
4 terminal_type char (32) unaligned,
4 terminal_id char (4) unaligned,
4 line_type fixed bin,
4 number fixed bin,
4 pad4 fixed bin,
3 last_login_info,
4 time fixed bin (71),
4 terminal_type char (32) unaligned,
4 terminal_id char (4) unaligned,
4 line_type fixed bin;
/* End include file uc_validate_info.incl.pl1 */
The output data in the uc_validate_info structure is
self-explanatory. One important point, however, requires
highlighting. In the MCS answering service code, at any point in
the login or logout process (or even during process execution),
the Initializer process could display error or status messages
directly to the user by writing on the user's communications
MNA Answering Service Changes MTB751-03
channel. In the MNA environment, all messages must be buffered
or stored in data structures (such as the output data, above) and
transmitted to the login server process for displaying over the
user's connection since the Initializer process does not have the
means to interface with the various network connections.
Once uc_validate_info, as well as the relevant I&A variables in
the UTE, are filled in, uc_ls_validate_request_ calls uc_login_,
which performs the actual I&A. Its function is similar to the
first part of the module lg_ctl_, used for MCS, absentee, and
daemon logins, and is described below. uc_login_ returns an
error code, which, if zero, implies that the user has undergone a
successful I&A. It also completes the output data in
uc_validate_info. The error code and output info is packaged
into a login server response and sent to the login server. If
the error code is non-zero, the UTE is freed, otherwise it
remains as the primary data structure used to manipulate the
process (or dial/mc service) associated with the user I&A'ed.
2.1.1.1.4: uc_login_
The module which performs all the work of user validation (as
opposed to process creation validation) is uc_login_. It is
called by uc_ls_validate_request_ after the UTE and
uc_validate_info structures are filled in. This new module is
coded in such a way as to be able to handle absentee and daemon
logins, as well as interactive logins and is meant to be used as
a replacement for the first part of the I&A functions performed
by the current lg_ctl_ module. Currently, however, it is only
used by the login server, which in turn, is only used by DSA. It
performs the following functions, some of which are optional or
dependent on the process type: person id validation, password
validation, physical security breach checking, change argument
processing, authorization argument parsing, project id
validation, daemon MCACS checking, communications channel access
checking, and AIM authorization validation. If all these checks
are made successfully, the user is considered "logged in", an
audit message is entered into the answering service log, the
"whotab" is updated, the output data of the uc_validate_info
structure is completed, and other login instances of the user are
notified as appropriate. If any of the validation checks fail,
the user is denied login, and the error code parameter is set so
that the caller, uc_ls_validate_request_ can reject the validate
request, and an audit message indicating login denial is logged.
As far as MNA is concerned, each logged-in user has a UTE
regardless of whether there is a process associated with the
user. The uc_login_ module performs the validation and the user
remains logged in until the module uc_logout_ is called. After
uc_logout_ is called, the UTE reflects a no-longer logged in user
and is discarded. uc_logout_ performs the inverse operation of
MTB751-03 MNA Answering Service Changes
uc_login_, and is responsible for updating the whotab and
auditing a logout. The instances and circumstances in which
uc_logout_ is called are described later in this MTB.
Most of the login server requests operate on a validated (logged
in) UTE. After a successful validate request the answering
service provides a handle (ute.login_server_info.our_handle) to
be used by the login server in subsequent login server requests.
This handle is used to locate the UTE. One request, the "dial
request" can be sent to the answering service without having
undergone validation. This corresponds to the use of the dial
preaccess command without the "-user" control argument. In this
case, the handle provided in the "dial" request is zero, and the
answering service recognizes this as indicative of the fact that
no validation has been performed, and treats the dial connection
as having not been identified and authenticated. The other
requests, however, require already validated UTEs in order to be
processed.
2.1.1.1.5: Communications Channel Access Checking (or lack
thereof)
As mentioned in a previous paragraph, the MNA answering service
does not perform discretionary access control checking for
communications channel. The reason is due to the inability to
associate communications channel names with identifiable
terminals, systems, hosts, etc. Under DSA, for instance,
communication channel names (i.e. dsa.MUL1.0034) are not known
prior to connection time, and once connected, it is not possible
for the TCB (answering service, in this case) to determine
conclusively where the connection originated from. This
inability to locate the origin of the connection is a failing of
the DSA architecture, and cannot be corrected through Multics
software. Therefore, it is not practical to attempt to perform
access control checks based on the communications channel.
2.1.1.2: Process Request
During the course of a normal user login (as opposed to a dial or
message coordinator service request) a process may be manipulated
-- that is, a process may be created, destroyed, connected to, or
new_proc'ed. Each of these operations may be selected on the
login command line or via preaccess requests after a successful
login. Each results in the login server's sending a "process"
request to the answering service. Each of these sub-requests is
described separately below. All process requests are handled by
the module uc_ls_process_request_, which is simply a dispatcher
to such modules as uc_ls_create_request_, uc_ls_destroy_request_,
etc., which actually perform the work.
MNA Answering Service Changes MTB751-03
2.1.1.2.1: Create Sub-Request
"Create process" requests are handled by the module
uc_ls_create_request_. As with most requests, the handle
provided by the login server in the request is used to locate the
UTE which corresponds to the connection in question. The various
process creation variables (described in MTB-752 in the
description of the "create" request) are copied into the UTE and
the module uc_create_process_check_ is called to perform the
validation of these variables. This module performs the
remainder of the checks which are currently made by lg_ctl_ in
the non-MNA answering service. Thus, it is a fair statement that
in the MNA answering service, validation is performed by
uc_login_ and uc_create_process_check_, and in the non-MNA
answering service, by lg_ctl_. The MNA modules are coded in such
a way that they could replace lg_ctl_ when (if) MCS is converted
to use the login servers.
If uc_create_process_check_ returns a non-zero status code, then
the process creation is denied (and uc_ls_create_request_ audits
the denial). Otherwise, act_ctl_ is called to open the user's
account and uc_create_process_ is called to create the process
(and audit the process creation). In any case, a login server
response is constructed providing the status of the create
request. For successful process creations, the process id and
event channel used to start the process running are returned to
the login server. Any messages which the various modules
involved in process creation checking may have wished to display
for the user (such as act_ctl_ or load_ctl_ warnings) are
accumulated in a new buffer pointed to by
as_data_$ls_message_buffer_ptr. These messages are copied into
the login server create response and forwarded to the login
server to be displayed over the user's connection.
The "login server message buffer" is located through the static
variable as_data_$ls_message_buffer_ptr rather than a parameter
for the sake of convenience and because it obviated the need to
change the calling sequence of the modules that required it.
Although considered bad practice to rely on external static
variables, the answering service software is already plagued by
them and relies on them heavily. The AS convention for locating
tables and global AS variables is through the user of external
static variables, hence, the use of
as_data_$ls_message_buffer_ptr has enough precedent to justify
its use. This global buffer does not cause conflicts when more
than one process is attempting to log in because of the
non-blocking nature of the answering service. During login
server request processing, the answering service does not go
blocked and the use of the message buffer does not persist across
login server request processing.
MTB751-03 MNA Answering Service Changes
In the non-MNA process creation case, the answering service is
charged with sending the process its initial wakeup which causes
the process to leave its initial blocked state and begin running.
For synchronization purposes, since it is the login server which
must set up various communications channel data structures before
the process can attach its I/O switches, the answering service
merely provides the login server with the event channel over
which the login server can send the initial wakeup when
appropriate.
2.1.1.2.2: uc_create_process_check_
The module uc_create_process_check_ is tasked with checking with
accounting and load control, as well as with per-project and
per-user limits to determine whether a process can be created on
behalf of a user. As stated previously, this program mirrors the
latter half of lg_ctl_, which performs the parallel functions for
MCS, absentee, and daemon logins. In summary, these checks
include: checking PDT and SAT process limits, checking for
multiple logins (and warning other login instances), calling
act_ctl_ for accounting validation, validating the use of the
"-process_overseer", "-subsystem", "-ring", and "-outer_module"
control arguments, setting up other miscellaneous process
creation variables, and calling upon load control to ensure that
load limits are not exceeded. If all these checks are
successful, the value ute.uflags.proc_create_ok is set to true,
indicating to other programs that this UTE is validated for
process creation. If any of the limits are exceeded or any
checks are not passed, the login server is apprised of the error
and the process creation is denied. Any messages accumulated in
the process of authenticating the process creation are
accumulated in a buffer (as described above). Examples of such
messages are the "preemption" messages which appear during login.
2.1.1.2.3: uc_create_process_
If uc_create_process_check_ determines that the process creation
is allowed, uc_create_process_ is called by uc_ls_create_request_
to actually create the process. This module mirrors cpg_ for
non-MNA logins. uc_create_process_ ensures that the UTE is set
up for process creation (by checking ute.uflags.proc_create_ok),
sets up the Process Initialization Table (PIT), initializes the
hardcore process creation structure create_info, selects the
process directory logical volume, and calls hardcore
(hphcs_$create_proc) to create the process. If successful, it
calls act_ctl_ to note the process creation. Finally, the whotab
is updated with the various values that were not available at
login time (for example the number of load units). Any error
which occurs during the execution of uc_create_process_ is
MNA Answering Service Changes MTB751-03
returned to uc_ls_create_request_ in order that it can be
conveyed to the login server.
2.1.1.3: Connect Request
The module uc_ls_connect_request_ is invoked when the user, upon
login, wishes to connect his terminal to an existing disconnected
process and issues the "connect" request. In actuality, the
"destroy" and "new_proc" requests also implicitly connect the
user to the disconnected process before performing their
designated functions and a common module,
uc_setup_process_connect_ performs the connection.
uc_ls_connect_request_ begins by calling
uc_setup_process_connect_, described in the next paragraph. If
this succeeds (error code equal to zero) then the login server is
sent a response indicating success and the request processing is
complete. Similarly, if an error occurs, the login server is
informed of this via a response.
2.1.1.3.1: uc_setup_process_connect_
uc_setup_process_connect_ is the heart of disconnected process
manipulation, and, as mentioned above, is invoked for the
"connect", "destroy", and "new_proc" preaccess commands. As for
most login server requests, the UTE is located via the handle
supplied by the login server. Then, the module
uc_list_disconnected_procs_ is called to build a list of the
disconnected processes belonging to the user. If the process
number supplied on the login or pre-access command is outside the
bounds of the number of disconnected processes, an error code is
returned to the caller. If the process number corresponds to a
disconnected process, then the AIM authorizations of the current
connection (as determined in the validate request) and the
disconnected process are compared and, if not equal, the process
connection is denied (and audited). Otherwise, various variables
are copied from the new (active) UTE into the old (disconnected)
UTE prior to discarding the new UTE and switching to the
disconnected UTE. The login server is apprised of the handle
corresponding to the disconnected UTE in the login server process
response so that future interactions with the answering service
will identify the correct UTE (the UTE identified in the connect
request is discarded when a process connects to a disconnected
process). The data copied from the new (temporary) UTE includes
the login server's handle, the response event channel, the
termination event channel, and the login server's process id --
in short the information which links the current connection with
the login server handling that connection (which may, of course,
be different from the one which handled it originally). In fact,
there may have been no login server at all if the process was
originally connected via MCS. Further, the terminal-specific
MTB751-03 MNA Answering Service Changes
information about the current connection is copied into the
disconnected UTE (name, type, id).
The event channel associated with the disconnected UTE is
re-declared with the MNA process termination handler, since the
terminal handler may have been associated with the MCS answering
service (if the process originally connected through MCS). A
process connect audit message is logged and the new UTE is freed.
Then, the disconnected process is informed (via an update of the
terminal information in the PIT) of the new terminal-related
variables through a call to uc_set_pit_tty_info_ and the process
is placed in the "connected" state, and the PDT and whotab
updated to reflect this state. Finally, the login server
response is manufactured, which includes the new handle to use to
manage this connection, the process id of the process, and the
event channel over which the process is suspended. The login
server will, after the appropriate setup, send a wakeup over this
event channel to get the process running again.
2.1.1.3.2: uc_set_pit_tty_info_
This module, uc_set_pit_tty_info_ is merely a wrapper for the
call into hardcore, through the gate entry
hphcs_$set_pit_tty_info, which updates the PIT of the
disconnected process with the new terminal-related variables.
Among those updated are the terminal name, type, id, and outer
module.
2.1.1.4: Destroy Request
When the user issues the "destroy" preaccess request, the module
uc_ls_destroy_request_ is invoked through the login server
request mechanism. In a manner analogous to the "connect"
request, the module uc_setup_process_connect_ is called to
connect the user's connection to the disconnected process, as
described above. After the connection is complete, the variables
ute.destroy_flag and ute.logout_type are updated to reflect the
desire to destroy the process and the process destruction
sequence is begun. An in-depth discussion of the process
destruction code is described further on in this MTB. For the
purposes of this discussion, suffice it to say, that there are
two means of destroying a disconnected process: normal or
immediate. In the normal case, the process is sent a "trm_" IPS
signal and the answering service waits for it to terminate
gracefully before calling hardcore to really destroy the process.
In the immediate case, the IPS signal and process response are
bypassed and hardcore is called directly to immediately destroy
the process. The user specifies whether he wishes an "immediate"
process destruction via the "-immediate" control argument on the
MNA Answering Service Changes MTB751-03
login or pre-access command line. This control argument is
conveyed to the answering service in the login server request and
acted upon by uc_ls_destroy_request_.
Unlike some of the other login server requests, no response is
sent to the login server at the end of the request processing.
The process destruction code, which runs asynchronously with the
request processing is tasked with notifying the login server when
the process destruction is complete. This is described later
under "Process Termination Handler".
2.1.1.5: New_Proc Request
The pre-access "new_proc" request is handled by the module
uc_ls_new_proc_request_ which parallels the action of the
"destroy" request. Again, the module uc_setup_process_connect_
is invoked in order to connect the user to the disconnected
process. Then, the variables ute.destroy_flag and
ute.logout_type are set to indicate to the process destruction
code that the process is to be new_proc'ed and the process
destruction sequence begun. Again, the "-immediate" option
applies, as described above. In addition, this request defers
the login server notification as in the case for the "destroy"
request.
2.1.1.6: List Request
The "list" request is used when the user wishes to get a list of
the disconnected processes he has. The module which processes
this login server request is uc_ls_list_request_. It determines
the UTE of the validated user based on the handle and then calls
uc_list_disconnected_procs_ to build a list of disconnected
processes. This list is copied into the login server "list"
response structure and sent to the login server.
2.1.1.6.1: uc_list_disconnected_procs_
Uc_list_disconnected_procs_ is charged with building a list of
the disconnected processes for a given user. It scans the
answer_table for processes whose person and project ids match
those of the requesting user which are also disconnected. As a
cross-check, it compares the number of processes found with the
number of disconnected processes recorded in the Project
Definition Table Entry (PDTE) for the user. Any errors are
recorded in the answering service log. The number found in the
PDTE is used to determine the size of the structure to allocate
-- if it is smaller than the number actually found in the
answer_table, then this smaller number of disconnected processes
is returned to the user. Normally, these numbers should be
MTB751-03 MNA Answering Service Changes
identical and will only differ due to bugs in the answering
service.
2.1.1.7: Disconnect Request
The login server "disconnect" request results when the login
server is notified from the underlying network software that the
connection to Multics has been terminated (disconnected). The
parallel in MCS is a "hangup" condition which arises
asynchronously. When the login server detects such a condition,
it notifies the answering service through a "disconnect" request
so that the answering service can log out or disconnect the
process. A disconnect request can occur for a user even before a
process is created (as, for instance, would happen if a user
logged in but didn't specify what was to be done with
disconnected processes, and while in the middle of the so-called
"connect-loop" dialog, hung up his terminal). In this case, the
answering service must still log out the UTE associated with the
connection. If there is a process associated with the UTE, then
it must be either logged out or disconnected, depending upon the
setting of the administrative and user flags.
The "disconnect" request begins by finding the relevant validated
UTE based upon the login server handle. If the process does not
have a process (ute.active = NOW_LOGGED_IN as opposed to
NOW_HAS_PROCESS) then uc_logout_ is called to log out the user
(and audit the logout). The UTE is then freed and the disconnect
request is complete. If the UTE has a process, then the "process
termination handler" is run by sending a "hangup" wakeup over the
event channel specified in ute.event. This causes the module
uc_proc_term_handler_ to be run, whose operation is described
later.
2.1.1.8: Logout Request
The "logout" request is a special request invoked when a user
issues the "logout" pre-access command, after already having been
logged in, but before having specified what to do about
disconnected processes he might have. Its operating is simple --
it calls uc_logout_ to log out the specified UTE and then frees
the UTE. This request is handled by uc_ls_logout_request_.
2.1.1.9: Dial Request
The "dial" request is invoked as a result of issuing the "dial"
pre-access command and is handled by the program
uc_ls_dial_request_. This request is different from the others
in that it can be sent to the answering service with or without
prior identification and authentication. In the case where no
MNA Answering Service Changes MTB751-03
I&A has occurred, there is no UTE associated with the connection
(this being the first time the AS has heard about it). This
situation is detected by the answering service by virtue of there
being a handle equal to zero in the request. If the handle is
non-zero, the UTE is found in the same manner as for other
requests. For zero handles, no UTE is involved in the operation
of the dial request. The module uc_dial_ actually performs the
work of locating the process to which the user wishes to solicit
dial service. If it returns a non-zero error code, and there is
a UTE active for the connection, the UTE is logged out and freed
and the login server is notified of the dial failure. For a
successful dial, the dial response is filled in and sent to the
login server, which displays the appropriate information on the
user's terminal.
2.1.1.9.1: uc_dial_
The module uc_dial_ is tasked with locating the process to which
the user's dial request applies. Its parallel in the MCS
answering service is a portion of dial_ctl_. This program is
passed the UTE of the dialing process (if present), the dial
qualifier, target person id and project id (if this is an
unregistered dial service), the user's connection name and access
class range. The return arguments are a pointer to the target
process's UTE (if any) and an error code. The operation of this
module is identical with that of dial_ctl_. It searches through
all UTEs in the answer_table, daemon_user_table, and
absentee_user_table looking for processes which are accepting
dials with the specified dial-id. It also performs an AIM check
to ensure that the target process access authorization lies
within the range of the connection access class of the dialing
user. It also ensures that the user's login authorization
dominates the authorization of the target process. Successful
and failed dial attempts are audited. For successful dials, the
count of dialed terminals is incremented in the target UTE.
Under MNA, the answering service does not provide the wakeup to
the target process indicating to it that a user has dialed. This
function is performed by the login server. The login server
response for a dial request provides enough information,
including the event channel name and process id of the target
process to allow it to send the notification.
2.1.1.10: Operator Request
The Operator request is sent to the MNA answering service when a
user specifies "-operator" on the login command line, indicating
that he wishes to become an operator and to have his terminal
converted to a message coordinator terminal. Use of "login
-operator" is functionally equivalent to issuing the "dial system
MTB751-03 MNA Answering Service Changes
-user Personid.Projectid" preaccess request. Under MCS, the
required use of "-user" to provide I&A was dictated by the
existence of the "check_acs: slave_dial" in the CDTE of the
channel over which the user was attempting the dial. Under MNA,
where it is not possible to know where a user is located (and
thus whether the user is an operator in the computer room), the
login server requires I&A for operator access. Rather than
require the "dial system -user Personid.Projectid -auth
Authorization" syntax, MNA allows a normal login command line to
specify the "-operator" control argument, which has the same
effect. The MCS answering service is NOT being upgraded to
include this functionality, although it would not take much
effort.
The "operator" request is handled by the module
uc_ls_operator_request_. Although the login server enforces I&A,
the answering service is equipped to handle the case where an
operator request is sent to the AS without a prior validation.
In this case, the Person Id and Project Id of the user are set to
null in the call to the message coordinator. Since the login
server does not allow this situation, operators will always have
undergone I&A and the message coordinator will be apprised of the
validated Person Id and Project Id.
The work of the operator request is performed by the subroutine
mc_commands_$mc_login, which is documented in MTB-750. Due to
the complexity of the message coordinator software, the answering
service does not send a response to the login server if
mc_commands_$mc_login returns a zero error code. The
notification is performed later (asynchronously). However, if
the message coordinator returns a non-zero error code, then the
login server is notified of the failure of the operator request.
One additional parameter may be specified on the login command
line for operator logins, namely the name of the desired virtual
channel to be associated with the message coordinator console.
Its use is documented in MTB-750 and the name of this virtual
channel (provided to the answering service in the operator
request) is merely passed to the message coordinator in the call
to mc_commands_$mc_login.
2.1.2: LOGIN SERVER REQUEST PROCESSING
The mechanism used to handle login server responses deserves some
comment. When uc_ls_rq_server_wakeup_ receives a wakeup from a
login server indicating that there is a login server request to
process, it examines the messages in the queue, checking them for
correct headers and lengths, and then processes them. After
processing them, they are deleted from the queue. Processing a
message involves determining the request type from the header of
the request and invoking the corresponding handler (these
MNA Answering Service Changes MTB751-03
handlers were documented in the previous section). If any error
occurs in trying to locate the handler or in decoding the
request, then an IPC message is sent to the login server with an
appropriate error code. Once the handler has been located, it is
called with various arguments; they include a pointer to a global
request server structure (declared in the include file
ls_request_server_info.incl.pl1), a pointer to and length of the
request, a pointer to a temporary segment used for the reply, a
return argument of the length of the reply (initially 0), a
pointer to the ls_reply_message structure used to communicate
errors using IPC (in the event that no reply message is used),
and an error code. If the length of the reply message is
non-zero upon return from the handler, a User Message (UM) is
sent to the login server containing a copy of the reply structure
(although the structure is not known by uc_ls_rq_server_wakeup_).
If the special flag ls_reply_message.do_not_reply is set after
the handler's return then no IPC message is sent to the login
server, otherwise, one is sent including the error code and flags
in the ls_reply_message structure. This versatile mechanism
allows errors to be communicated between the answering service
and login server through a combination of an IPC message and a UM
message, either of which is optional (although there are no
instances where a UM message is sent without an IPC message).
Some requests, as described above, defer sending a response until
some later time.
uc_ls_rq_server_wakeup_ sends its login server responses by
directly calling the UM facility. The asynchronous replies (sent
by uc_proc_term_handler_, as described in the next section) use
the module uc_send_ls_response_ to send the UM. This module is
merely a wrapper for the call to the UM facility and provide an
easier calling interface than the UM facility directly.
222...222::: PPPrrroooccceeessssss TTTeeerrrmmmiiinnnaaatttiiiooonnn HHHaaannndddllleeerrr
Associated with every validated UTE is an event call channel
whose handler is tasked with handling various events associated
with the user to whom the UTE belongs. The handler for MNA is
uc_proc_term_handler_; for the non-MNA answering service, the
handlers are dialup_, ftp_dialup_, absentee_user_manager_ and
daemon_user_manager_ (for interactive, ftp, absentee, and daemon
logins, respectively). The kinds of events which are handled by
uc_proc_term_handler_ include requests from the user process to
logout, new_proc, or handle a fatal process error; operator bump,
disconnect, terminate, and detach commands; communications
channel disconnection notifications, and hardcore process
termination reports.
The wakeups which are handled by the process termination handler
may arrive from three sources: the user process in the user
ring, any user process in ring zero, and the answering service
MTB751-03 MNA Answering Service Changes
itself (in ring 4). Before processing the wakeup, the answering
service must ensure that if it originated from outside of ring
zero and was not sent by the answering service, that it was sent
by the process to which the UTE associated with the event channel
belongs. When the event channel is set up, the UTE pointer is
used as the IPC data pointer, such that whenever a wakeup is
received, uc_proc_term_handler_ can tell what UTE is associated
with the wakeup. The IPC event_call_info data provides the
identity of the sending process allowing the answering service to
ensure that a malicious user is not attempting to affect another
user's process. This validation is performed for any wakeups
that come in over the process termination event channel and
invalid wakeups are logged.
The IPC event message determines the action which the process
termination handler should take. These messages are defined in
the tables as_data_$signal_types and as_data_$system_signal_types
-- the former defining the wakeups which can be sent by the user
process and the latter listing those which can only be sent by
hardcore or the answering service (bump, for instance, cannot be
sent by a user process). Basically, uc_proc_term_handler_ is a
big transfer vector which decodes the IPC wakeups, validates
their origin, and transfers (using a computed goto) to a label
indexed by the wakeup type. There are several different classes
of wakeups, each described in more detail below:
2.2.1: FATAL PROCESS ERROR WAKEUPS
When a user process gets a fatal process error, the user-ring
process termination code sends a wakeup to the answering service
(over the process termination event channel left in the PIT by
the answering service) indicating the type of fatal process error
(and error code, if applicable). Fatal process errors include
process initialization errors and are all handled by similar code
in uc_proc_term_handler_. The basic function of the handlers for
all these fatal process cases is to record an error code in a
"fatal process error response" to be sent to the login server,
destroy the old process, create a new process. (Actually, the
situation is complicated slightly in that if the answering
service detects that the user is in a fatal process error loop
(by counting the number of fatal processes in a site-specified
time interval), it does not create a new process, but instead
logs the user out. Further, an "AS Request" provides the user
with the option of specifying whether a new process is to be
created upon a fatal process error, or whether the user is to be
logged out.) Finally, the login server is notified of the
process termination and new process information. The mechanism
for destroying processes and creating new ones is described
later.
MNA Answering Service Changes MTB751-03
2.2.2: NEW_PROC WAKEUPS
When the user issues a "new_proc" or "new_proc -auth" command (or
the subroutine equivalents), a wakeup is sent to the answering
service (over the process termination event channel). If a new
authorization is requested for the process, this authorization is
validated. In the case of a requested change of access
authorization, the trusted_path_login flag is checked first to
ensure the site allows changes in authorizations without first
undergoing I&A again (logging out and logging in). After the
validations, if any, the old process is destroyed and a new one
created (at the desired authorization). The login server is
notified of the new process attributes (process id, event
channels, authorization, etc.) when the new process is created
so that it can update its connection info, display an
authorization banner, and start the process executing (in a
similar manner to when a process is created initially). This new
process information is conveyed to the login server through the
means of the "new_proc login server response".
2.2.3: LOGOUT WAKEUPS
The logout command causes a "logout" wakeup (with various
options) to be sent to the answering service. If the user
specified the "-hold" control argument to the "logout" command,
the answering service verifies that the trusted_path_login
installation parameter is disabled -- otherwise, it ignores the
"-hold" request. Then, the process destruction code is branched
to (described later) and the login server notified of the logout.
2.2.4: HANGUP WAKEUP
The "hangup" request is a privileged request which can come from
two sources: the operator "disconnect" command, and the login
server's "disconnect" request. In either case, the user's
save_on_disconnect flag is checked and if the process is to be
saved on disconnect, then it is disconnected by setting the
"disconnect" flag in the UTE, and attempting to suspend the
process (by sending it a sus_ signal). If the suspend works
correctly, the "suspended" flag is set in the UTE. If the
save_on_disconnect flag is off, a "logout" request is simulated.
2.2.5: BUMP, SHUTDOWN, TERMINATE, DETACH WAKEUPS
The operator "bump", "detach", "stop", and "terminate" requests
cause the process termination cycle to begin (see below) with an
appropriate error code stored in the login server's termination
response structure. The bump command provides some grace
MTB751-03 MNA Answering Service Changes
(implemented through a timer in the answering service process)
before beginning the process termination cycle.
2.2.6: UNBUMP WAKEUP
The operator unbump request disables the grace time timer set by
a bump request.
2.2.7: HANDLING OF DESTROY AND NEW_PROC PREACCESS REQUESTS
In prior sections, the handling of the "destroy" and "new_proc"
preaccess commands, and the resulting login server requests, was
described. The action of these requests, culminated with the
calling of dpg_ to destroy the process. Just prior to calling
dpg_, these requests set the value of the variable
ute.destroy_flag in order to signal to the process destruction
software that after destroying the process, the login server
required a "process response" rather than a "termination
response". Two new process termination states, the
"NEW_PROC_REQUEST" and "DESTROY_REQUEST" are recognized by
uc_proc_term_handler_ when the process is destroyed and the
appropriate code is branched to to notify the login server of the
completion of the request.
2.2.8: OTHER WAKEUPS
There are five wakeups not yet described which are involved in
the process termination sequence of events. These are:
"trmsgnl", "alarm", "stopstop", "termstop", and "cpulimit".
These are described in more detail in the following section on
the process destruction cycle.
2.2.9: THE PROCESS TERMINATION CYCLE
Perhaps the most interesting and complicated aspect of the user
control segment of the answering service surrounds the process
termination code. There are three ways in which this code can be
entered. The first is through a request from the user (logout,
new_proc); the second is forced by the answering service (bump,
terminate, shutdown, etc.); and the third is through the
"destroy" and "new_proc" login server requests, as described
above. Each of these classes of terminations is described below.
2.2.9.1: User-Initiated Process Terminations
When a user process wishes to terminate itself, it first sends
the answering service an appropriate wakeup indicating why it is
MNA Answering Service Changes MTB751-03
terminating (logout, new_proc, fpe) and then calls
hcs_$stop_process to actually cause hardcore to stop running the
process. The user wakeups were described above. Upon receipt of
a process termination request, uc_proc_term_handler_ sets a
variable in the UTE, ute.destroy_flag to either WAIT_LOGOUT,
WAIT_LOGOUT_HOLD, WAIT_NEW_PROC, WAIT_DESTROY_REQUEST, or
WAIT_NEW_PROC_REQUEST in order for the answering service to
remember what to do after the process is completely terminated.
It is important to realize that the answering service cannot go
blocked waiting for a process to terminate, but rather has very
well-defined places where it does go blocked and must be equipped
to handle all interactions as asynchronously as possible. Thus,
it sets flags for itself in the UTE and when the next wakeup
comes in, it picks up where it left off and continues the process
termination sequence. Once ute.destroy_flag is set
appropriately, dpg_ is called to destroy the process. dpg_
(after various house-cleaning tasks, including process
destruction auditing) calls hardcore to begin destroying the
process. Hardcore notifies the answering service (sometime
later) with a "stopstop" wakeup to indicate that the process is
indeed stopped. When the "stopstop" wakeup is handled by the
answering service, it calls hardcore again to finish destroying
the process. act_ctl_ is called to indicate process destruction
and the value of ute.destroy_flag is examined to determine what
to be done next. This may involve creating a new process or
logging the user out. In any case, the login server is notified
through a process termination response or new proc response of
the actions taken.
2.2.9.2: System-Initiated Process Terminations
Operator commands, such as bump, detach, terminate, etc. take a
different route through the process termination sequence since
these are not initiated by the user process. First of all, the
user process is notified of the impending termination by sending
it a "trm_" IPS signal. This allows the process to run "finish"
condition and "epilogue" handlers before being destroyed. In the
normal case (where the process is not hung up in some way nor
have its trm_ signal masked), the process's trm_ signal handler
cleans up the process and then sends the answering service a
"trmsgnl" wakeup. This indicates to the answering service that
it is ok to proceed with the process termination -- and the same
sequence as described in the previous section for user-initiated
process terminations occur.
In the event that the user process cannot (or will not) respond
to the trm_ signal correctly, the answering service sets up a
realtime and cpu timer for the UTE. If the realtime timer runs
out, IPC sends an "alarm___" wakeup over the process termination
event channel. If the cpu timer runs out, hardcore sends a
"cpulimit" wakeup. In either case, the answering service
MTB751-03 MNA Answering Service Changes
responds by logging the fact that the process ignored the trm_
signal, and goes ahead with the process destruction by calling
dpg_. Both the "cpulimit" and "alarm___" wakeups are handled in
uc_proc_term_handler_.
Finally, there is one more case of system-initiated process
terminations. These involve timed terminations, accomplished by
specifying grace time in the bump request (or bump subroutines).
The answering service uses the UTE variable "ute.preempted" to
record state of the timed process termination, and
ute.destroy_flag to record what timed operation is to be
performed. It then sets a realtime timer for the process (the
wakeup for which will arrive on the event channel for which
uc_proc_term_handler_ is the IPC handler). When this wakeup
("alarm___") comes in, uc_proc_term_handler_ notices that a timed
event is in progress and performs the operation in the same
manner as it would have had there not been a timer.
2.2.9.3: Cleanup of Network Connections
When a process is destroyed, dpg_ is called. One of the tasks of
dpg_ is to clean up process resources such as RCP devices,
logical volumes, and dialed connections. Under MNA, dialed
connections may be MNA connections, rather than MCS channels.
dpg_ calls dial_ctl_$dial_broom when a process terminates to
clean up dialed channels. dial_ctl_$dial_broom is augmented for
MNA to call uc_cleanup_network_dials_, which is charged with
cleaning up MNA connections. A database called the Active
Connection List, and documented in MTB-752, maintains a list of
all the active connections. uc_ls_cleanup_dials_ queries this
database looking for connections owned by the process being
destroyed and takes two actions:
o it calls the entrypoint defined in the
force_accounting_update_field to cause network accounting to
be updated with the latest figures for the connection and
o it notifies the login server that the process is being
terminated. This allows the answering service to write the
appropriate message on the dial user's terminal indicating
that the target process has terminated.
The dial_ctl_$dial_broom entry is also called when a process
wishes to terminate all dialed channels. In this case, the
reason for dial channel terminations is not process destruction,
but deliberate terminating by the process. This distinction is
made in the login server "response" sent by
uc_cleanup_network_dials_.
MNA Answering Service Changes MTB751-03
333::: CCCHHHAAANNNGGGEEESSS TTTOOO MMMCCCSSS AAANNNSSSWWWEEERRRIIINNNGGG SSSEEERRRVVVIIICCCEEE MMMOOODDDUUULLLEEESSS
Several of the existing answering service modules used to manage
MCS interactive users, absentee processes, and daemons were
modified to accommodate the MNA changes. These changes are
highlighted below.
333...111::: UUUssseeerrr TTTaaabbbllleee CCChhhaaannngggeeesss
Section 2.1.1.1.1 discusses elements added to the user table
entry (UTE) in Answer Table, Absentee User Table and Daemon User
Table to support MNA. In addition, all data elements in the UTE
structure were reordered to group data by logical function.
Data items common to the header of each user table were placed in
a shared substructure declared in the new ut_header.incl.pl1
file. This allows entries in all three tables to be allocated,
freed and reset by a new routine, the user_table_mgr_.
The format_attributes_ subroutine was modified to use
USER_ATTRIBUTE_NAMES declared in the user_attributes.incl.pl1
structure, eliminating the need for a separate
attribute_names.incl.pl1 file.
dump_anstbl_, which displays the headers and entries in the three
user tables, was modified to display user table header and UTE
items in the new order, with interpretation provided for most
items.
333...222::: dddpppggg_
dpg_ is the module called to perform process destruction. It has
two entrypoints, dpg_$dpg_ and dpg_$finish. The dpg_$dpg_ entry
was modified to take an additional argument, the reason for the
process destruction (logout, new_proc, etc.) so that this reason
could be passed to dial_ctl_$dial_broom (used to clean up dial
connections). The MCS answering service modules each used to
perform process cleanup prior to calling dpg_. Since the process
cleanup code was common for all cases, it is now moved into dpg_.
The call to dial_ctl_$dial_broom required a reason code, hence
the new parameter to dpg_. Of course, dpg_ was modified to call
dial_ctl_$dial_broom, lv_request_$cleanup_process (to get rid of
logical volume attachments), and rcp_sys_$unassign_process (to
clean up RCP attachments).
333...333::: dddiiiaaalll_ccctttlll_
dial_ctl_ is the module which handles dial connections for MCS
processes. Its $dial_broom entry (which is called when a process
MTB751-03 MNA Answering Service Changes
is destroyed) has been updated to include a call to the new
module uc_cleanup_network_dials_, tasked with cleaning up MNA
connections other than the login channel.
dial_ctl_ was also modified to expand aliases in dial preaccess
requests.
333...444::: dddaaaeeemmmooonnn_uuussseeerrr_mmmaaannnaaagggeeerrr_,,, aaabbbssseeennnttteeeeee_uuussseeerrr_mmmaaannnaaagggeeerrr_,,, ffftttppp_dddiiiaaallluuuppp_,,,
aaannnddd dddiiiaaallluuuppp_
daemon_user_manager_, absentee_user_manager_, and ftp_dialup_
were modified for the new calling sequence of dpg_ and to remove
the calls to dial_ctl_$dial_broom, lv_request_$cleanup_process,
and rcp_sys_$unassign_process (since these calls are now
performed by dpg_).
Additionally, absentee_user_manager_ was modified to send the
wakeup to release a suspended absentee. This wakeup used to be
sent by asu_$release_suspended_process, but since this latter
module was modified to not send this wakeup (since in the MNA
case, the wakeup is sent by the login server), the callers of
asu_$release_suspended_process must send the wakeup themselves.
All 4 user managers were modified to call user_table_mgr_ to
allocate, free and reset entries in their user table.
333...555::: aaasss_aaacccccceeessssss_aaauuudddiiittt_,,, aaacccccceeessssss_ooopppeeerrraaatttiiiooonnnsss_,,, dddiiiaaalll_ccctttlll_ aaannnddd lllggg_ccctttlll_
as_access_audit_ is the module which is supposed to be
responsible for generating all answering service audit messages.
For MNA, two new entrypoints were added to this code, $login and
$logout to perform the access auditing required when a process is
logged in and logged out respectively. The information in the
audit record is extracted from the UTE, passed as an argument.
For MCS, lg_ctl_ was changed to call these new entrypoints to
generate login/logout auditing messages, rather than generating
these messages directly. For MNA, uc_login_ and uc_logout_ call
the new entrypoints to perform the auditing.
Three new access operations were added to the access_operations_
segment, to audit the dialin, dialout and dial_system operations.
as_access_audit_$channel was changed to use these new operations.
For MCS, dial_ctl_ was modified to call as_access_audit_$channel
to audit these operations. For MNA, uc_dial_ and
mc_commands_$mc_login call as_access_audit_$channel to audit
these operations.
Finally, the format of all audit messages produced by
as_access_audit_ was standardized to start with an operation name
MNA Answering Service Changes MTB751-03
(eg, LOGIN, CREATE, ATTACH, DIALIN, etc), followed by DENIED if
the operation was denied, followed by process identification
information and any additional information associated with the
operation.
333...666::: cccooonnnvvveeerrrttt_aaacccccceeessssss_ccclllaaassssss_
A new $maximum access class range was added to determine the
maximum of a set of access classes. Change lg_ctl_ and uc_login_
to use the new entrypoint to determine the upper bound of a
process authorization range from values in the SAT, PNT and PDT.
See documentation for the new entrypoint in Appendix A.
333...777::: UUUssseeerrr MMMeeessssssaaagggeee FFFaaaccciiillliiitttyyy
This facility allows the Initializer to send detailed information
to a user process (such as communication channel access class
information, system warnings, etc). It is also used by the
Login_Server for the same purpose (to send communication channel
information to the user process). The facility was modified to
correct several errors in module calling sequences, and to sort
messages by message ID when the user_message_admin_$read_message
function is called.
333...888::: lllooogggiiinnn_ssseeerrrvvveeerrr_ooovvveeerrrssseeeeeerrr_$$$ttteeesssttt
login_server_overseer_ is written as a process overseer to
control the Login Server process. However, its $test entrypoint
can be invoked as a command to establish a test login server
environment. This can interface either with the real user
control environment running in the Initializer, or with a test
user control environment, to facilitate debugging of login server
software.
333...999::: ttteeesssttt_sssyyysssttteeemmm_cccooonnntttrrrooolll,,, rrruuunnn_ttteeesssttt_aaasss
Two commands were added to test the system control and user
control environments in a normal user process. This greatly
simplifies debugging of changes to Answering Service.
An sc_stat_$test_mode flag was added to indicate execution in a
test environment. test_system_control and run_test_as set this
flag, attach the Initializer's I/O switches to the user's login
channel, and start up the environment.
test_system_control invokes the full ring 4 system control
environment, using a user-specified system control directory. At
ring 4 command level, the user can then type multics, go or
MTB751-03 MNA Answering Service Changes
startup to invoke various flavors of the user control
environment.
run_test_as does not initialize the system control environment;
it just initializes the standard user control environment. It
can be used to quickly enter the test user control environment
without having to go through system control.
The current implementation of both commands only allows testing
of MNA user control. This can be done by using the login server
test environment to send process validation/creation/etc requests
to the test user control environment rather than to the real user
control environment.
No provision was made for testing MCS user control, because this
would require sharing channels in the CDT with the real user
control software running in the Initializer process. This
sharing capability was too difficult to add now, but could be
added in the future if needed.
333...111000::: aaasss_iiinnniiittt_
as_init_ is called from system control to initialize the
answering service. This code was cleaned up substantially, so it
is easier to follow. It was also modified to support the
Answering Service test environment.
333...111111::: aaacccttt_ccctttlll_ aaannnddd llloooaaaddd_ccctttlll_
These two modules, responsible for accounting and load control,
respectively, tied the existence of a Channel Definition Table
Entry (CDTE) to interactive processes. Under MNA, interactive
processes do not have CDTEs. Modifications to these programs
were required in order to remove the dependency on CDTEs. Fields
which were only available in the CDTE (and not in the UTE) were
added to the UTE. Attempts to write on user's terminals directly
were conditionalized based on the existence of a CDTE. For
CDTE-less connections, error and warning messages ("preemption"
and "account limit" messages, for example), messages are buffered
in a new "login server message buffer". A pointer to this buffer
is maintained in the database as_data_. If the size of the
buffer is too small for a new message about to be added, the
buffer is reallocated and the new size stored in as_data_. The
login server request mechanism sends the contents of this buffer
to the login server for display on the user's terminal.
When act_ctl_ and load_ctl_ were modified to place warning
messages in the new message buffer when no CDTE was available, it
was discovered that daemon process logins caused messages to
accumulate in the buffer. This is because the old code always
MNA Answering Service Changes MTB751-03
attempted to write on the "terminal" of daemon processes, but
since none existed, nothing happened. With the new
modifications, these message did accumulate and would be saved
around until the next MNA login. lg_ctl_ was modified to clear
out the buffer after MCS, daemon, and absentee logins. In fact,
this change is not really required, because the MNA software also
clears this buffer out before every process creation attempt.
In addition, act_ctl_$dp is changed to call
hpriv_connection_list_$get_next_user. It then calls the
entrypoint defined in the force_accounting_update_field to cause
network accounting to be updated with the latest figures for the
session.
333...111222::: aaasss_dddaaatttaaa_
This database of static variables used throughout the answering
service is updated for MNA with a pointer to the login server
message buffer, and the current and maximum sizes of this buffer.
Additionally, the pointer to the login server request server data
structure is stored in as_data_. Finally, the version number of
the answering service increases to 17.0 (from 16.1) with the
changes for MNA.
333...111333::: aaasssuuu_
asu_ contains quite a few "answering service utility"
subroutines. New utilities were added to provide subroutine
interfaces for bumping, terminating, disconnecting, etc. user
processes. The actual implementation of these commands
previously resided in the admin_ procedure which implements the
operator commands. These commands all interfaced directly with
the process termination code by sending the appropriate wakeups
over the process termination event channel. Because this
interface is really an internal answering service interface, it
was decided not to have the commands themselves interface with
the process termination software, but to call subroutines to
perform the work.
Additionally, the asu_$asu_remove entrypoint was modified for the
new calling sequence of dpg_ and to remove the calls to the
various process resource clean up routines, as described in a
previous section.
333...111444::: aaasss_ccchhheeeccckkk_cccooonnndddiiitttiiiooonnn_
This module decides how to handle unexpected conditions detected
in Answering Service routines. It was modified to pass
MTB751-03 MNA Answering Service Changes
command_error and command_question signal on to the default
handler.
333...111555::: mmmuuullltttiiicccsss_llliiibbbrrraaarrriiieeesss_
The standard library descriptor for the Multics system libraries
was modified to include the DSA software added to >sl3p>dsa.
MNA Answering Service Changes MTB751-03
AAAPPPPPPEEENNNDDDIIIXXX AAA::: SSSUUUBBBRRROOOUUUTTTIIINNNEEE DDDOOOCCCUUUMMMEEENNNTTTAAATTTIIIOOONNN
The following documentation changes go into the Multics
Subroutines manual.
_____________________ _____________________
convert_access_class_ convert_access_class_
_____________________ _____________________
NNNaaammmeee::: cccooonnnvvveeerrrttt_aaacccccceeessssss_ccclllaaassssss_
EEEnnntttrrryyy::: cccooonnnvvveeerrrttt_aaacccccceeessssss_ccclllaaassssss_$$$mmmaaaxxxiiimmmuuummm
This entry point accepts an array of access attributes and a
binary number indicating how many elements to process from the
array. It returns an access class whose category set is the
union of all input category sets and whose sensitivity level is
the maximum of all input sensitivity levels. The returned value
need not equal any of the input values, nor be a proper superset
of all the input values.
USAGE
declare convert_access_class_$maximum entry
(dim(*) bit(72) aligned, fixed bin, bit(72) aligned);
call convert_access_class_$maximum (acc_att_array, n_elements,
maximum_acc_att);
ARGUMENTS
acc_att_array
are the input access attributes. (Input)
n_elements
is the number of elements to be processed in the acc_att_array
argument. (Input)
maximum_acc_att
is the resulting access class. (Output)
MNA Answering Service Changes MTB751-03
AAAPPPPPPEEENNNDDDIIIXXX BBB::: SSSYYYSSSTTTEEEMMM AAADDDMMMIIINNNIIISSSTTTRRRAAATTTIIIOOONNN PPPRRROOOCCCEEEDDDUUURRREEESSS
The following are documentation changes to the System
Administration Procedures (SAP) manual, AK50-03A, Section 25,
beginning on page 25-21.
IIIdddeeennntttiiifffiiicccaaatttiiiooonnn aaannnddd AAAuuuttthhheeennntttiiicccaaatttiiiooonnn (((III&&&AAA)))
When a user logs in to the system, the user's person_id is
identified (Identification); when the password is entered, the
system authenticates (Authentication) that the user is actually
the person_id entered. I&A messages perform three functions:
o security auditing
o a journal of all system logins and logouts
o notification of user logins for operators
Note that since the answering service log contains information
about aborted login attempts, mistyped user passwords may be
identifiable in the log. It is important that you safeguard the
answering log from unauthorized access.
The format of I&A messages recorded in the answering service log
is:
LOGIN {DENIED} <user_id> <process_type> <channel_id>
{[<absin_entry>]} {(<added_info>)}
LOGOUT <user_id> <process_type> <channel_id>
{<cost_info>} (<added_info>)
where:
<user_id>
is the Person.Project of the authenticated user at login, or
Person.Project.Tag of the user at logout. An anonymous Person
identifier is preceded by an asterisk (*).
<process_type>
is one of the following types of authentication:
int an interactive process.
Q n an absentee process (where n is the background
queue number or FG for a foreground process).
dmn a daemon process.
opr a message coordinator operator login.
<channel_id>
MTB751-03 MNA Answering Service Changes
is the FNP channel name for an interactive process, the
absentee slot number for an absentee process, the message
coordinator stream for a daemon process, or the message
coordinator console name for operator users.
<absin_entry>
is the final entryname of the absin file associated with an
absentee login.
<added_info>
is a string giving circumstances for the login authentication,
or the logout. For interactive, absentee and daemon processes
this will be a mnemonic string generated by the software.
This may be the login word used, the disconnected process
control argument given to login, the reason for the logout,
etc. Some examples are: login, enter, enterp, create,
connect, new_proc, logo, autologout, lhbr, bad_pers, bad_pass,
term, etc. For operator users it will be "sign_on" or
"sign_off".
<cost_info>
is the VCPU time (in minutes and seconds) and dollar cost for
the session.
MNA Answering Service Changes MTB751-03
I&A messages are routed to the operator console as well as the AS
log. The following are sample I&A audit messages recorded in the
answering service log.
LOGIN RRitter.TSDC int c.h000.002 (create)
LOGIN Wallman.Multics int b.h010.001 (connect loop)
LOGIN DENIED EMarch.BETA int c.h000.001 (bad_pass)
LOGIN TR_Admin.TR Q FG abs2 [update_user_regs] (create)
LOGIN DENIED Network_Server.Daemon Q 4 abs2 (umxbg)
LOGOUT Hirneisen.SysAdmin.a int c.h016.001 0:38 $1.05 (lobr)
LOGOUT Volume_Dumper.Daemon.z dmn vcons 15:25 $18.77 (logo)
The interpreted binary data for I&A Audit messages consists
of the standard header information described earlier in this
section. LOGOUT messages have no additional binary data. LOGIN
messages have extra binary data that is interpreted by
print_sys_log as follows:
Process type = <process_type>,
Min ring = <min_ring>, Max ring = <max_ring>,
Attributes = <process_attributes>,
Audit flags = <process_audit_flags>,
Channel = <channel_id>,
Terminal type = <term_type>,
Answerback = <answerback>,
{Absentee input path = <absin_path>}
where:
<process_type>
may be interactive, absentee, daemon, or operator
<min_ring>
is the minimum ring number at which the process is allowed to
be authenticated
<max_ring>
is the maximum ring number at which the process is allowed to
be authenticated
<process_attributes>
are the attributes for the user combined from the PNT and SAT
entries. Only those which are "on" are listed. A complete
list can be found in the description of the "new_user"
command.
<process_audit_flags>
are the per-process audit flags for the user combined from the
PNT and SAT entries. A description of the flags can be found
in the description of the "new_user" command.
MTB751-03 MNA Answering Service Changes
<channel_id>
is the name of the login communications channel, the abs user
slot number, the message coordinator stream, or the message
coordinator console channel name as appropriate for the type
of process.
<term_type>
is the type of terminal
<answerback>
is the terminal's answerback
<absin_path>
is the pathname of the absin file associated with an absentee
process.
MNA Answering Service Changes MTB751-03
PPPrrroooccceeessssss MMMaaannniiipppuuulllaaatttiiiooonnn
The answering service log records events related to user
process manipulation. The format of process manipulation audit
messages is:
<key> <user_id> <channel_id> <process_id> {<reason>}
where:
<key>
may be one of: CREATE, DISCONNECT, CONNECT, DESTROY, or
CONNECT DENIED.
<user_id>
is the Person.Project.Tag associated with the process
<channel_id>
is the communications channel name, the absentee slot name, or
the daemon stream name as appropriate for the type of user.
Note that there are no process manipulations for operator
users since there are just authenticated, not given a process.
<process_id>
is the octal process unique identifier.
<reason>
is a mnemonic generated by the system describing the reason
for the process creation, destruction, or disconnect. Some
expamples are: new_proc, login, bump, destroy, logo, hangup,
hngp, cpg, init, ucs, term, lhbr, logi, etc. For "CONNECT
DENIED" messages this field will be the communications channel
authorization and the authorization of the disconnected
process.
The interpreted binary data for process manipulation audit
messages contains only the header described in the first section.
There is no additional data specific to process manipulation.
The following are sample user process manipulation audit
messages recorded in the answering service log.
13:04:53 1123341 0 CREATE Swenson.SysMaint.a a.h028 006600751323 (login)
13:18:11 1123365 0 DISCONNECT EJSharpe.MULTICS.a a.h102 006300751314 (hangup)
13:24:00 1123383 0 DESTROY IO.SysDaemon.z prta 005400021626 (logo)
13:34:33 1123406 0 CONNECT EJSharpe.Multics.a a.h103 006000751314
MTB751-03 MNA Answering Service Changes
CCCooommmmmmuuunnniiicccaaatttiiiooonnnsss CCChhhaaannnnnneeelll
The answering service records information relating to
communications channels. The types of communications channels
events that are recorded are:
o dial-out requests
o slave attachments
o dial-in requests
o test and diagnostic (T&D) attachments
AUDIT MESSAGE FORMAT FOR COMMUNICATIONS CHANNEL ATTACHMENT
The text portion of audit messages associated with
communications channel attachment are of the general form:
<to_key> {DENIED} {<incoming_user_id>} channel <channel_id>
to <user_id> <process_id> {<service_info>} {(<reason>)}
<from_key> {DENIED> channel <channel_id>
from <user_id> <process_id> {<service_info>} {(<reason>)}
where:
<to_key>
may be one of: ATTACH, DIALIN or DIAL SYSTEM.
<from_key>
may be one of: DETACH or DIALOUT.
<incoming_user_id>
is the Person.Project given in the -user control argument of
the dial preaccess command for DIALIN and DIAL SYSTEM
operations.
<channel_id>
is the name of the communications channel.
<user_id>
is the Person.Project.tag of the user requesting the ATTACH,
DETACH or DIALOUT operation, or of the target user process of
a dial preaccess command for a DIALIN or DIAL SYSTEM
operation.
<service_type>
is the channel service type (dial_out or slave) for an ATTACH
or DETACH operation, the destination for a DIALOUT operation,
or the dial identifier for a DIAL IN operation.
MNA Answering Service Changes MTB751-03
<added_info>
is one of the strings listed in the appendix which describe
additional circumstances about the event
The interpreted binary data for communications channel audit
messages bears the standard header as previously described.
Following this header is data formatted as follows:
Channel name = <channel_id>,
{Current access class = <channel_auth>,}
{Access Class Range = <channel_auth_range>,}
{Current service type = <service_type>,}
{Service type = <service_type>,}
{Terminal type = <terminal_type>,}
Userid = <user_id>
MTB751-03 MNA Answering Service Changes
where:
<channel_id>
is the name of the communications channel.
<channel_auth>
is the authorization at which the channel will be used.
<channel_auth_range>
is the range of authorizations within which the channel may be
used.
<service_type>
is the service type of the channel (login, ftp, mc, slave,
dial, dialout, inactive, mpx, or t&d).
<terminal_type>
is the type of the "terminal" on the channel
<user_id>
is the Person.Project of the process which has the channel
attached, or the Person.Project of an authenticated user
dialing into a process.
The following are examples of communications channel
attachment audit messages recorded in the answering service log:
DIALOUT channel f.h024.d02 from GDixon.SysMaint.a 016200115221 Destination=*
ATTACH channel f.h024.d02 to GDixon.SysMaint.a 016200115221 Service=dial_out
DETACH channel f.h024.d02 from GDixon.SysMaint.a 016200115221 Service=dial_out (hangup)
DIALOUT channel b.h022 from Lippard.Multics.a 016600115447 Destination=9 555-7316
DIALOUT DENIED channel b.h022 from Lippard.Multics.a 016600115447
(Unable to complete connection to external device. error in dialing out)
DETACH DENIED channel acu.* from Lippard.Multics.a 016600115447 Service=terminate dial out
(Resource not known to the system. Channel acu.* does not exist.)
DIALIN channel b.h004.001 to Network_Server.Daemon.z 005400114731 Dial ID=smtp
ATTACH channel b.h004.001 to Network_Server.Daemon.z 005400114731 Service=dial_in
DETACH channel b.h004.001 from Network_Server.Daemon.z 005400114731 Service=dial (hangup)
MNA Answering Service Changes MTB751-03
The following new access operations should be added (in
alphabetical order) to the Table B-1 in appendix B.
TEXT
OBJECT TYPE OPERATION TYPE ENTRY NAME
cancellation of absentee job
OTHER MODIFY abs_command_cancel
dial channel into Initializer message coordinator
SPECIAL MODIFY dial_system
dial channel into process
SPECIAL MODIFY dialin
dial out from process through channel
SPECIAL MODIFY dialout
installation of a system table
SPECIAL MODIFY install_table
invalid online MCA request
OTHER READ invalid_mca
lock of MCAs
OTHER MODIFY_ACCESS lock_mca
request of login of absentee job
OTHER MODIFY abs_command_login
| terminating process
| SPECIAL UNKNOWN process_terminate
|
unlock of MCA
OTHER MODIFY_ACCESS unlock_mca
MTB751-03 MNA Answering Service Changes
AAAPPPPPPEEENNNDDDIIIXXX CCC::: PPPRRRIIIVVVIIILLLEEEGGGEEEDDD IIINNNTTTEEERRRFFFAAACCCEEESSS MMMTTTBBB
The following commands should be added to the Privileged
Interfaces MTB.
___________________________ ___________________________
login_server_overseer_$test login_server_overseer_$test
___________________________ ___________________________
NNNaaammmeee::: lllooogggiiinnn_ssseeerrrvvveeerrr_ooovvveeerrrssseeeeeerrr_$$$ttteeesssttt
SYNTAX AS A COMMAND
login_server_overseer_$test {test_sc1_dir {test_info_dir}} {-pb}
FUNCTION
This command establishes a test version of the login server
environment in the caller's process. In this environment, the
standard login server requests are available. In addition,
normal Multics commands can be issued by preceding them with ..
to escape from the login server ssu_ environment. This feature
can be used to issue cpm_call commands to manipulate the control
points listening on endpoints or managing connections.
ARGUMENTS
test_sc1_dir
pathname of the directory containing test versions of
answering service databases to be used by the login server.
Login server requests are sent to the login_server_requests.ms
queue in this directory.
test_info_dir
pathname of the directory containing the three Login Server
subsystem info directories, which contain info segments
describing the subsystem requests. Three subdirectories must
reside in test_info_dir:
login_server_info
login_info
login_connect_info
-probe, -pb
when control points report an error, calls probe after
reporting the error to allow a chance for further debugging.
By default, execution continues within the control point after
the error is reported.
ACCESS REQUIRED
To use this command, access is required to the
network_accounting_gate_, user_message_priv_ gate, and
login_server_requests.ms queue.
___________________________ ___________
login_server_overseer_$test run_test_as
___________________________ ___________
NNNaaammmeee::: rrruuunnn_ttteeesssttt_aaasss
SYNTAX AS A COMMAND
run_test_as test_sc1_dir
FUNCTION
This command establishes a test version of the Initializer's user
control environment in the caller's process. In this
environment, the standard operator requests are available to
manipulate user processes created by the test environment.
Process can be created for Multics Networking Architecture (MNA)
interactive user, absentee users and daemon users.
ARGUMENTS
test_sc1_dir
is the pathname of the user directory to be used as the system
control directory. You must specify a directory other than
>sc1 to avoid interfering with the real user control running
in the Initializer process.
ACCESS REQUIRED
This command requires access to a variety of privileged gates
needed to initialize the System Control and User Control
environments. These include hpriv_connection_list_ and
network_accounting_gate_.
NOTES
The pathname of a test >sc1 directory must be given as an
argument to this command. Do not use the real >sc1 directory, or
you will interfere with operation of the real system control
environment in the Initializer process.
The test >sc1 directory should already contain all segments
needed to run the system control and user control environments.
If segments are missing or incorrectly formatted, error messages
will result and the environment initialization will fail. The
user control environment is not highly robust, so fatal process
errors (although not common) may occur if things are improperly
setup.
___________ ___________________
run_test_as test_system_control
___________ ___________________
The best way to setup the directory is to refer to the
acct_start_up.ec to see what needs to be in the test >sc1
directory. After the test directory is built, invoke this
command and fix all errors which result. Another (more
frustrating) approach is to invoke this command with an empty
directory and fix the errors, reinvoke and fix the new errors,
etc.
WARNING: The system control environment plays with the I/O
switches. Do not expect it to work in anything but a virgin
environment (no auditing, no video). And don't be surprised if
your favorite commands (emacs) won't work once you've started the
test environment. After exiting the test environment, a new_proc
is recommended to cleanse the user process.
________________________________________
NNNaaammmeee::: ttteeesssttt_sssyyysssttteeemmm_cccooonnntttrrrooolll
SYNTAX AS A COMMAND
test_system_control test_sc1_dir
FUNCTION
This command establishes a test version of the system control
environment in the user's process. In this environment, the
standard operator requests are available to start user control
functions for the Multics Networking Architecture (MNA), absentee
processing, the message coordinator environment, daemon
processes, etc.
ARGUMENTS
test_sc1_dir
is the pathname of the user directory to be used as the system
control directory. You must specify a directory other than
>sc1 to avoid interfering with the real system control running
in the Initializer process.
ACCESS REQUIRED
This command requires access to a variety of privileged gates
needed to initialize the System Control and User Control
environments. These include hpriv_connection_list_ and
network_accounting_gate_.
___________________ ___________________
test_system_control test_system_control
___________________ ___________________
NOTES
The pathname of a test >sc1 directory must be given as an
argument to this command. Do not use the real >sc1 directory, or
you will interfere with operation of the real system control
environment in the Initializer process.
The test >sc1 directory should already contain all segments
needed to run the system control and user control environments.
If segments are missing or incorrectly formatted, error messages
will result and the environment initialization will fail. The
system control environment is not highly robust, so fatal process
errors (although not common) may occur if things are improperly
setup.
The best way to setup the directory is to refer to the
acct_start_up.ec to see what needs to be in the test >sc1
directory. After the test directory is built, invoke
test_system_control and fix all errors which result. Another
(more frustrating) approach is to invoke test_system_control with
an empty directory and fix the errors, reinvoke and fix the new
errors, etc.
___________________ ___________________
test_system_control test_system_control
___________________ ___________________
Minimum contents of a test >sc1 subtree is shown below.
>UDD>DSA>AS>test_sc1
seg admin.ec
seg cdt
seg sat
seg sat.ht
seg sat.install.acs
seg ssu.ec
link mgt >sc1>mgt
link installation_parms >sc1>installation_parms
rate_structure_0
link rtdt >sc1>rtdt
link syserr_log >sc1>syserr_log
msf PNT.pnt
seg 0
seg 1
dir as_logs
seg admin_log
seg log
dir pdt
seg SysAdmin.pdt
seg SysMaint.pdt
seg SysDaemon.pdt
seg Operator.pdt
seg Multics.pdt
dir update
Empty
Other segments will be created when starting up the test system
control and user control environments and their subsystems.
WARNING: The system control environment plays with the I/O
switches. Do not expect it to work in anything but a virgin
environment (no auditing, no video). And don't be surprised if
your favorite commands (emacs) won't work once you've started the
test environment. After exiting the test environment, a new_proc
is recommended to cleanse the user process.