02/27/85 register_resource, rgr Syntax as a command: rgr type STR1 ... STRN {-control_args} Function: makes a particular resource known to the system. The registration process informs the system that the resource is available for users who are authorized to access it. Arguments: type is a resource type defined in the RTDT. See "Reserved Names" below for additional information. STRi is the unique identifying name of the particular resource being registered. If STR is specified in control argument format (i.e., if it is preceded by a hyphen), then it must be preceded by -name or -nm. (The string "scratch" is not permitted.) Control arguments: -access_class accr, -acc accr sets the initial AIM access class parameters, where accr is an access class range. Users at any authorization within the access class range inclusive are allowed to read and write to the resource (provided they also meet other access requirements). -acs_path path specifies the pathname of the access control segment (ACS) for this resource. The ACS is not created by this command, but must be created by the administrator, and the desired access control list set (see "Notes" below). If this control argument is not given, the accounting owner of the resource is given rew access by default. If path is a null string, the existing ACS, if any, is disassociated from the resource. -alloc STR sets the allocation state of the resource to free or allocated, where STR must be either the string on or the string off. If this control argument is not given, the allocation state is free. (The allocation state flag is a convenience to the user and is largely ignored by resource management.) on sets the allocation state to allocated off sets the allocation state to free -attributes STR, -attr STR specifies the initial values for the attributes of this resource. If this control argument is not given, the default attributes defined in the RTDT for this resource type are used (see "Naming Rules for Attributes" below). -comment STR, -com STR specifies the initial value of the comment string for this resource. -location STR, -loc STR specifies a descriptive location for the resource, to aid the operator in locating it when it is stored in a special place (e.g., a vault, a different room, etc.). -lock STR locks or unlocks the resource, preventing or allowing use of that resource, where STR must be either the string on or the string off. If this control argument is not specified the lock is off. on prevents any use of the resource off allows use of the resource -owner STR, -ow STR specifies that this resource, as part of the registration process, is to be acquired on behalf of the user specified by STR. If STR is the string "system", then the resource is acquired to the system pool. If STR is of the form Person_id.Project_id (where neither Person_id nor Project_id may be a star), then the user specified has all the rights of ownership to the resource as if he had acquired it personally, except that if -release_lock on is specified, the owner may not release (give up ownership of) the resource voluntarily. If this control argument is not given, the resource is entered by default into the free pool. -potential_attributes STR, -pattr STR specifies the potential attributes to be assigned to this resource. If this control argument is not given, the default potential attributes defined in the RTDT for this resource type are used (see "Naming Rules for Attributes" below). -potential_access_class accr, -pacc accr sets the potential AIM access class parameters, where accr is the access class range. Users at any authorization within the access class range inclusive are allowed to acquire the resource. If the control argument is not given, the default potential access class defined in the RTDT for this resources type is used. See "Access Class Ranges" below, for additional information. -release_lock STR, -rll STR specifies whether this resource may be released by the owner, or may only be released by a privileged process. The STR argument must be either the string on or the string off. It is primarily useful to implement special arrangements between a site and a user whereby the user agrees to pay a fixed amount for the privilege of administrative power over a resource for an agreed-upon length of time. If this control argument is not specified, the resource may be released by the owner (does not require special privilege). on resource may only be released by privileged processor off resource may be released by owner -type subtype_name, -tp subtype_name specifies that defaults for this resource are to be taken from the description of the resource subtype as defined in the RTDT (see "Application of Defaults" below for additional information). Notes: If multiple resources are specified to the register_resource command and an error occurs in the registration of any of these resources, none of the resources specified is registered. If no -owner is specified, the resource is placed in the free pool. The use of the -access_class, -acs_path, -attributes, or -comment control argument requires that the -owner control argument be specified. Access required: The use of this command requires execute access to the rcp_admin_ gate. Certain specifications of AIM access class parameters (e.g., an access class lower than the user's current authorization) are rejected unless the user has the AIM rcp privilege. Notes on access control: There are three types of access control on Multics, discretionary access control, which is regulated by access control lists (ACL); nondiscretionary access control, which is regulated by the access isolation mechanism (AIM); and intraprocess access control, which is regulated by the ring structure. (For detailed information on types of access, see the Multics Programmers' Reference Manual, Order No. AG91.) Notes on access control segments: An important feature of RCP is its ability to control access to the various resources that it manages. It does this through the use of access control segments (ACSs). An ACS is a zero length segment whose ACL and ring brackets are used to define the discretionary access to a resource. RCP uses an ACS for each resource that it controls; however, an ACS can be shared by more than one resource. The name of an ACS consists of a name plus the suffix, acs (e.g., tape_01.acs). There are no restrictions on ACS names other than the required suffix. The user creates an ACS and generates/manipulates its ACL with the create, set_acl, and delete_acl commands and ring brackets with the set_ring_brackets command. The pathname of the ACS for a resource is usually specified when it is acquired. The specified ACS can later be changed via the set_resource command (see the Multics Commands and Active Functions manual, Order No. AG92). If the ACS has not been specified or does not exist, access is by default rew for the owner of the resource and null for all other users. RCP uses the ACS along with other nondiscretionary controls (AIM) to determine the RCP effective access to a resource. Notes on access class ranges: Access class ranges are used by RCP to specify that a process within a range of authorizations can use a particular resource. An access class range is simply a pair of AIM access classes separated by a colon. The first value of the pair is the minimum access class and the second is the maximum access class. If only a single access class is specified when an access class range is expected, the minimum and maximum access class values are both the same (i.e., a range of one value). The second access class of the pair (the maximum) must be greater than or equal to the first (the minimum). The user should be aware of results which occur when categories are used in an access class range. For example, a process with authorization of level2,category1 would not be able to use a resource whose access class range was level1,category1,category2:level3,category1,category2,category3 where level3 is greater than level2, which is greater than level1. This is due to the fact that the authorization of the process is isolated from the minimum of the access class range. In order to allow this process access to the resource in question, the range would have to exclude category2 or the user would have to have category2 authorization. In general, to include categories within an access class range, both the minimum and maximum must include the categories desired. If combinations of categories are desired, the minimum should list only required categories and the maximum should include all categories allowed. For example, the access class range level1,category1:level3,category1,category2,category3 allows read and write access to any level1, level2, or level3 process with category1 and any combination of category2 and category3. Notes on RCP effective access: Viewed separately, each type of access control answers the same question, "What access does a particular process have for a particular item?" The access mode granted a process to a resource by discretionary access control (the ACL) is known as the raw access mode. The way RCP determines effective access to a resource for a process differs from the regular Multics method of determining effective access as follows. First, the effective access to the ACS for the resource is determined as for any segment. If the ACS does not exist, the user appears to have read, execute, and write access if he is the owner of the resource, or null access if he is not the owner. Then, two further checks are made. First, the current authorization of the process is compared to the maximum access class of the resource. If write access is not allowed (as defined by the write_allowed_ subroutine) then write and execute access are denied and only read is allowed. Next, the current authorization of the process is compared to the minimum access class of the resource. If read access is not allowed (as defined by the read_allowed_ subroutine) then all access is denied. The resulting access is termed the RCP effective access to the resource. One final restriction enforced by RCP is that, in order to use a device, the RCP effective access must include both read and write to that device (a restriction not imposed on volumes). A user must have write RCP effective access to the resource named to perform any modification on the status of the resource. In addition, the user must have execute effective access to the resource named to modify protected attributes. Only the accounting owner may modify the ACS path. For more information on AIM, access classes, authorizations, and comparisons involving access classes and authorizations, see the Multics Programmer's Reference manual, Order No. AG91. Notes on manipulating RCP effective access: Since the access control mechanisms described above operate together to determine the RCP effective access of a process, there are actions that the user, as well as an administrator, can perform to control this effective access. First, the user creates an ACS via the create command. Then, the desired ACL for that segment is established using the set_acl command to add desired ACL entries, and the delete_acl command to delete entries. (The above three commands are described in the Multics Commands and Active Functions manual, Order No. AG92.) To further affect the ACS, the user may modify its ring brackets by using the set_ring_brackets command (described in the Multics Commands and Active Functions manual, Order No. AG92). The system security administrator sets the AIM access class range of the resource itself at the time it is registered using the register_resource command, and can change it by using the set_resource command. Notes on reserved names: RCP uses the information in the RTDT to decide what classes of resources are known to the system, how they are to be handled, and what important attributes they possess. In the initial implementation, sites may use this flexibility to augment the standard complement of attributes for certain resources. For example, a site with tape drives in more than one location may register these drives with an additional simple attribute, thereby allowing users to request assignment of a tape drive in the remote location. Additionally, the tape reels in the remote location may be tagged with a matching attribute, marked in the RTDT as requiring that attribute of its tape drive. Although this mechanism is very flexible, the necessity of having certain standard and reserved resource type names and attribute names cannot be avoided. Standard software (e.g., tape and disk I/O modules) needs to refer to a domain of resources by standard names, as well as certain attributes of the resources. Since these strings must be the same at all sites, certain resource types and certain resource attributes must be contained in all RTMFs. The cv_rtmf command checks for their existence and refuses to process an RTMF that lacks them. This list of required resource type names and attributes is also found in the include file, rcp_mandatories.incl.pl1. RCP does not allow the name "scratch" to be used in registering a resource. A scratch tape is one of the unmarked tapes in an unreserved pool that is used for "scratch"--that is, no information is saved on it from session to session. After every use, it is demounted and returned to the system pool. List of reserved resource names: The following resources are mandatory and must appear in all RTMFs. Device: disk_drive Device: tape_drive Volume: tape_vol Volume: disk_vol List of reserved attribute names: The following attributes are mandatory for the devices named, and must appear in all RTMFs. For the disk_drive device model=400 model=451 model=181 model=191 model=500 model=402 For the tape_drive device track=7 track=9 den=200 den=556 den=800 den=1600 model=400 model=500 model=600 model=610 Notes on naming rules for attributes: Attributes provide a description of a volume or device that assists the resource management facility in the proper matching of volumes with compatible devices. To produce correct combinations, attribute names must comply with the set of rules described below. Attributes may be grouped or ungrouped. Grouped attributes specify a set of properties applicable to a device or volume such that only one attribute of that set can be currently active at any given time. For example, a reel of tape may have potential attributes that allow it to be recorded at densities of 556, 800, or 1600; however, at any given time, the data on it is in only one of those densities. Grouped attributes have names of the form shown below. = For example, the attributes mentioned above are named "den=556", "den=800", and "den=1600". This notation allows RCP to recognize that any request to make one of these attributes the current attribute of a device or volume also implies that all other attributes in that grouping must be made inactive. When adding or changing an attribute in a string of attributes, all attributes in the string must be respecified or else existing attributes are nullified by the change. Also, any attribute string must contain a value for each grouped attribute. For example, if the attribute domain includes "track=..., model=..., and den=...," the device you are setting the attributes for (or registering) must contain values for each grouped attribute. Ungrouped attributes have simple names, such as "trainok" (to specify that this device accepts a removable print train) or "building_12" (to specify that this device or volume is located in building 12). Notes on application of defaults: When the system administrator registers a resource, that resource may be registered using the defaults for the registration parameters that are specified in the RTDT. Alternately, he may explicitly specify parameters for which defaults may also be specified in the table, such as attributes and AIM classes. If any such parameter is explicitly specified, the corresponding default for that parameter is overridden. When the resource is registered, any default parameters defined for that resource type are applied in the absence of a corresponding explicitly specified parameter. If the resource is registered with the "-type " control argument, any default parameter defined for the special class named is applied in the absence of a corresponding explicitly specified parameter. In the case of duplicate resource type and special class parameters, the special class default parameters override the general resource type parameters. In addition, any default parameters specified for that resource other than those defaults in the special class are applied. If no special classes of a resource are defined, and the defaults for the resource are not all present, it is always necessary for the missing parameters to be explicitly specified for every registration request for a resource of this type. If special classes of a resource are defined, then defaults within the definition of special classes can be used either to replace corresponding defaults specified for the resource in general, or to supplement for missing defaults that are not specified for the resource in general. In the latter case, the system administrator cannot perform a simple default registration of the resource, but must either specify the missing items explicitly in the command line, or use the "-type " control argument to take advantage of the additional defaults provided in a special class. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved