Message control systems (MCSs) differ from other interactive programs in that they interface directly to the data comm subsystem (rather than opening a remote file) in order to send or receive messages from terminals. This interface is possible because MCSs are written in DCALGOL, an extended version of ALGOL with special data comm capabilities. The system extends a number of special privileges to MCSs.
How an MCS Acquires Its Privileges
The MCS security privileges and MCS priority are not granted to a program simply because it is written in DCALGOL; the system must also recognize the program as an MCS. Two things are necessary for the system to recognize a program as an MCS:
-
Each MCS on a system must be named in the data comm network definition for that system. Note that the system disregards the family name portion of the MCS code file title when comparing the title with the data comm network definition. Only one MCS of a given name can be active.
-
The MCS must invoke the DCALGOL DCWRITE function to initialize its primary queue. Every MCS must have such a queue and must initialize it in order to be recognized as an MCS.
The system removes MCS status from a process if either of the following events occurs:
Priority of an MCS
An MCS automatically runs in the same priority category that control programs run in. This priority category gives the MCS higher priority than WFL jobs and application programs. However, the priority of an MCS is lower than that of any invisible independent runner. The priority of MCSs relative to each other is determined by the PRIORITY task attribute. For an explanation of process priority, refer to Controlling Processor Usage. For a discussion of how and when this special priority can be inherited by offspring of an MCS, refer to “Inheritance of MCS Status” later in this section.
Privileges of an MCS
When an MCS first initializes its primary queue, the system grants that MCS all the privileges associated with privileged status, as discussed under Privileged Status earlier in this section. This is true even if the MCS is running under a nonprivileged usercode and has not been marked as a privileged program.
However, if the MCS changes its usercode, the system reevaluates the privileged status of the MCS. Thereafter, the MCS receives privileged status only if one of the following conditions is true:
-
The MCS is running without a usercode.
-
The MCS is running under a privileged usercode, and the MCS did not request lesser privileges when changing to that usercode. (Refer to the discussion of USERDATA function 3 later under this heading.)
-
The MCS object code file has been marked with privileged status.
Additionally, an MCS receives a number of privileges that are unique to MCSs. These privileges are retained by the MCS regardless of the usercode under which the MCS runs. The following paragraphs describe these unique privileges and features of MCS status.
An MCS is allowed the following privileges with regard to the USERDATA function:
-
Ability to use USERDATA function 3 to assume a usercode without supplying the corresponding password.
When an MCS uses USERDATA function 3 to temporarily assume a usercode, the MCS does not appear in GETSTATUS mix request calls that request mix entries with that usercode. The MCS also does not appear in the output from system commands that display the mix and that request mix entries with that usercode.
By default, the MCS inherits any of the following types of privileges that are associated with the new usercode: privileged status, security administrator status, SYSADMIN status, and SYSTEMUSER status. However, the MCS can use the USERDATA locator parameter to limit the privileges the MCS can receive from the new usercode. The locator parameter can specify separate limits for each of these types of privileges.
For an example of a program that uses USERDATA function 3, refer to Temporarily Assuming an Identity later in this section.
-
Ability to change a user's password with USERDATA function 6, subfunction 1, which is normally disallowed on a system using password generation.
-
Ability to call the USERDATA function to validate a usercode/password combination or, optionally, a usercode without the password. This USERDATA function allows the MCS to run with the specified usercode so the MCS can perform a function on behalf of that usercode.
-
Ability to call the USERDATA function to validate a usercode/chargecode combination.
-
Ability to call the USERDATA function to validate an accesscode/accesscode password combination.
-
Ability to call USERDATA function 9 (Privileged Fetch and Examine).
-
Ability to specify that the last log-on information for a usercode should be updated as a result of the current USERDATA call.
-
Ability to survive USERDATA errors that would normally be fatal. The errors are returned in the USERDATA error result field.
An MCS receives the following special privileges with regard to other restricted DCALGOL functions:
-
Ability to call the DCWRITE function, which handles station message traffic.
-
Ability to call the MCSLOGGER function, which creates sessions or logs session activity.
-
Ability to survive SETSTATUS errors that would otherwise be fatal. The SETSTATUS error reporting mechanism returns the error to the MCS process.
-
Trusted status that causes the operating system not to perform validation on any mix numbers specified by the MCS in SETSTATUS calls.
An MCS receives the following special privileges with regard to initiating processes:
-
Ability to survive errors in initiating an external object code file, such as security errors, that would otherwise be fatal. Also, the ability to attempt to initiate a missing external code file without becoming suspended with a NO FILE condition. The MCS can determine if initiation was successful by inspecting the task variable used in the process initiation statement. If initiation failed, the STATUS task attribute has a value of BADINITIATE. The reason for the failure is reported in the HISTORYTYPE, HISTORYCAUSE, and HISTORYREASON task attributes.
-
Ability to pass a single array parameter to an offspring process by value instead of by reference.
-
Trusted status that causes the operating system not to perform validation of any sheet array parameter the MCS passes when initiating a compiler.
An MCS receives the following special privileges with regard to task attribute access:
-
Ability to survive task attribute errors that are normally fatal. The MCS can determine whether an error occurred, and the type of error, by interrogating the TASKERROR task attribute of the task variable that was accessed.
-
Ability to commit task attribute errors in reading a task attribute without any error messages resulting.
-
Ability to assign values to the JOBNUMBER and SOURCESTATION task attributes.
-
Ability to modify the NAME task attribute value of a running process.
-
Ability to modify the CHARGE task attribute of a running process. Note that the MCS should check the validity of the new CHARGE value before assigning that value.
An MCS has the following special privileges with regard to file access:
-
Ability to invoke the exported MCP procedure CHANGESECURITY, which changes the security attributes of files.
-
Ability to survive security errors that occur while changing file security.
-
Ability to call the exported MCP procedure DRCDETERMINEUSERLIMITS, which reports on the file usage limits imposed on a user by the disk resource control (DRC) system.
-
Ability to exceed DRC limits at file open time without any error messages being displayed.
-
Ability to set the HSFILECOPY file attribute, which then allows an MCS to modify various “read only” disk file attributes such as CREATIONDATE, CREATIONTIME, and TIMESTAMP.
An MCS has sufficient privilege to access library objects that have a linkage class of 3. For information about library linkage classes, refer to Security Considerations for Libraries in Using Libraries.
Inheritance of MCS Status
In some cases, it can be useful for an MCS to initiate one or more tasks to handle some of its work. By default, these tasks do not receive any special privileges as a result of being initiated by an MCS. These tasks also do not receive the special MCS priority category, and by default they receive a PRIORITY task attribute value of 50 rather than inheriting the PRIORITY value of the MCS.
However, the MCS can grant MCS privileges and priority to any of its offspring by assigning a value of TRUE to the INHERITMCSSTATUS task attribute of the offspring.
