.ifi init_plm "FS-00"
.srv draft ""
.srv draft_date ""
.srv section %Arg1%
.pdl 66
.ifi l0h "Access Control - dc_find"
     Internal to directory control is the module dc_find.  It is responsible
.ifi hit "K|dc_find"
for locating directories and directory entries for the file system primitives.
In the process of locating these entities, dc_find makes the necessary access
checks, auditing successful accesses and attempted access violations when
necessary.  Indeed, dc_find is the enforcer of the systems' security policy
within the file system.

     Much of the operation of dc_find is explained in the section on directory
control mechanisms.  This section provides a few more details.  Its main
purpose, though, is to explain the systems' security policy (with respect to
the file system) and to list the various access checks (i.e., functions)
available within dc_find.
.ifi l1h "Basic Security Model"
     Multics possesses three different security measures: ACLs, AIM and rings.
.ifi hit "K|security policy~basic"
These mechanisms are well described in the Reference Guide and will not be
explained here.

     The access modes a process has to an object depends on some combination
.ifi hit "S|security policy~ACL~see ACL, also properties, ACL"
.ifi hit "S|access control list~see ACL"
of the user's presence in the ACL of the object, the user's AIM authorization
versus the object's AIM classification, and the user's ring (normally the
user's validation level) versus the ring brackets of the object.  The access
modes a user has on an object determined by only calculating the access modes
.ifi hit "S|access isolation mechanism~see AIM"
.ifi hit "S|security policy~AIM~see AIM, also properties, AIM"
given by the ACL of the object is called the user's "raw" access modes.  If
the AIM classification calculation is factored in, the resulting access modes
.ifi hit "K|access modes~raw"
.ifi hit "K|access modes~authorization"
.ifi hit "K|access modes~effective"
are referred to as the user's "authorization" access modes.  Finally, if ring
.ifi hit "S|security policy~ring brackets~see ring brackets"
bracket computations are also factored in, the resulting access modes are
referred to as the user's "effective" access modes.

     Whether or not a given process is allowed to perform a specific access to
an object is a function of the access modes the process has on the object, the
access modes the process has on the object's directory entry (that is, the
process' access modes on the parent directory), the access modes the process
has on the parent's directory entry, and so on, depending on the type of
access being attempted.
.ifi l2h "Basic Access Catagories"
     The basic access catagories revolve around getting and setting the three
main classes of properties of a file system object.  These are listed below.
A more detailed description of what properties are considered to be within
these classes, as well as what access operations are not (strictly) in these
classes, is provided later.
.ifi l3h "Contents Properties"
     The contents properties of a segment are the machine words that
.ifi hit "S|security policy~contents properties~see properties, contents"
.ifi hit "K|properties~contents"
constitute the segment.  The security requirements for accessing these words
are based on the effective access modes the user possesses to the segment.
This is enforced by the hardware, given the authorization access modes and the
.ifi hit "S|segment descriptor word~see SDW"
.ifi hit "K|SDW"
ring brackets of the segment, inserted into the segment's SDW by dc_find on
behalf of segment control.

     The bit count of a segment is also a contents property of the segment
.ifi hit "K|properties~bit count"
(but only when the attempted access is to set the bit count).  The security
requirement for setting this content property is the same as for writing into
the segment; that is, the effective access modes must include "w" permission.

     The contents properties of a directory are the IACLs of the directory,
the list of names within the directory (but not the entries they represent)
and the quota cells for the directory.  The security requirement for getting
.ifi hit "K|properties~IACLS"
.ifi hit "K|properties~name list"
these properties is that the effective access modes must include "s"
permission.  The security requirement for setting these properties is that the
effective access modes must include "m" permission.

     The bit count (MSF component indicator) of a directory is also a contents
.ifi hit "S|MSF component indicator~see properties, bit count"
property of the directory (but only when the attempted access is to set the
bit count).  The security requirement for setting this content property is
that the effective access modes must include "m" permission if the bit count
is to be decreased (implying a decrease in the number of components in the
MSF) and the effective access modes must include "a" permission if the bit
count is to be increased (implying an increase in the number of MSF
components).

     There are no contents properties for links.
.ifi l3h "Status Properties"
     The status properties of an object are those properties considered as
.ifi hit "S|security policy~status properties~see properties, status"
.ifi hit "K|properties~status"
belonging to the parent directory of the object.  These are the names and the
.ifi hit "K|properties~names"
.ifi hit "K|properties~ACL"
ACL of the object.  For links, the link target is also a status property.  

     The security requirements for getting a status property for an object is
that the effective access modes on the containing directory must include "s"
permission.  The security requirements for setting a status property for an
object is that the effective access modes on the containing directory must
include "m" permission.

     Accessing a status property of an object often requires that the user be
within the read bracket of the object for getting the property and within the
write bracket (or modify bracket) for setting the property.  The user need not
have any specific ACL or AIM relationship with the object.
.ifi l3h "Attribute Properties"
     The attribute properties of an object are almost all other properties.
.ifi hit "S|security policy~attribute properties~see properties, attribute"
.ifi hit "K|properties~attribute"
These are properties that the user is allowed to access given access to the
parent directory or access to the object.  The rational is that access to the
object allows the user to deduce these properties.

     The security requirements for getting an attribute property of an
object are that the effective access modes on the parent directory must
include "s" permission or the effective access modes on the object must be
non-null.  Attribute properties are normally considered the same as status
properties with respect to setting them.  Some, however, allow the setting of
the property if the effective access modes on the parent directory include "m"
permission or the effective access modes on the object include "w" (or "m")
permission.

     Accessing an attribute property of an object often requires that the user
be within the read bracket of the object for getting the property and within
the write bracket (or modify bracket) for setting the property.  The user need
not have any specific ACL or AIM relationship with the object.
.ifi l1h "Access Computations"
     The principle module concerned with determining a process' access to an
object is access_mode.  It computes the access a process has with respect to
.ifi hit "K|access_mode"
.ifi hit "K|access modes~computation"
the ACL, optionally factors in the AIM restrictions, and, optionally factors
in the ring brackets.

     access_modes determines the access to the root, since it has no ACL (or
directory entry, for that matter).  The extended access modes of the root are
.ifi hit "K|access modes~root"
"sma" to the Initializer (that which has a process id of
.ifi hit "K|access modes~Initializer"
tc_data$initializer_id) and "s" to everyone else, independent of ring and
authorization.  The raw/authorization segment access modes are "rw" to
everyone.  The effective segment access modes are "rw" only when in ring 0.

     Apart from the root, the Initializer is also given "rw" authorization
segment access to all directories and "sma" extended access to all
directories.

     In the normal case, access_modes finds the ACL from the directory entry
.ifi hit "K|access modes~raw"
and implements its own ACL match to determine the raw access modes.  Failure
to match returns zero for both segment and extended access modes, except for
directories for which all processes possess "rw" raw access.

     The AIM test follows, if authorization or effective access was desired.
.ifi hit "K|access modes~authorization"
.ifi hit "K|AIM"
If this is a directory and the user has AIM dir privilege, the raw access
modes stand; if this is a segment and the user has AIM seg privilege, the raw
access modes stand.  Otherwise, the test proceeds through tests of
read_write_allowed_ and read_allowed.  (The read_write_allowed_ check is
skipped if the user does not have "w" raw mode on the segment or "ma" raw mode
on the directory).  If the read_write_allowed_ check passes, the raw modes
stand.  If not, the read_allowed_ test is made.  If this passes, the raw modes
stand except that "ma" directory access or "w" segment access is forced off.

     If neither the read_write_allowed_ AIM test nor the read_allowed_ AIM
test pass, the user is given null access modes.  The exception to this is for
multi_class (as declared in the directory entry) segments whose execute
bracket are zero or one.  For these segments, if a write_allowed_ pass
succeeds, the raw access modes stand.

     The final tests made are when effective access is desired.  For segments,
.ifi hit "K|access modes~effective"
this involves a test of the segment ring brackets in the directory entry.  For
directories, this involves a check, first of the extended (directory) ring
brackets to find the extended access modes, and then the segment ring brackets
.ifi hit "K|ring brackets"
.ifi hit "S|ring brackets~see also properties, ring brackets"
to determine segment access modes.  The rules are: if the ring is less than or
equal to the "a" bracket, the extended modes stand.  If it is greater than the
"s" bracket but less or equal to the "a" bracket, "ma" access is deleted.
Otherwise, the access is null.  For segment acess the rules are: if the ring
is equal to the "w" bracket, the access modes stand.  If it is less than the
"w" bracket, "e" access is deleted.  If it is greater than the "w" bracket but
less than or equal to the "r" bracket, "w" access is deleted.  Otherwise, if
the ring is less than or equal to the "e" bracket, "rw" access is deleted.
Finally, if the ring is greater than the "e" bracket, all access is deleted.

     Note that this routine uses usage_values to meter itself in
active_hardcore_data.
.ifi l1h "Known Segment Access Maintenance"
     The authorization access computed by access_modes for a segment within
.ifi hit "K|access modes~maintenance~known segments"
the address space is stored within the SDW for the segment, as is the
segment's ring brackets.  This information is maintained in the SDWs by
.ifi hit "K|SDW"
segment control (actually by dc_find).  When the user's access to the segment
is potentially changed, the primitive performing the change requests that
.ifi hit "K|setfaults"
segment control perform a "setfaults" (by calling setfaults).  This segment
control primitive invalidates the SDW in every process that references the
.ifi hit "K|access modes~recomputation"
segment, forcing a recomputation of access at the next segment fault on this
.ifi hit "K|change_dtem"
segment in each process.  When setfaults is called, change_dtem is also, to
guarantee that the dtem in the branch is advanced by at least one, for a
reason explained below.

     The authorization access for segments is stored within the KST entry for
the segment.  The file system uses this information to optimize its
computation of authorization segment access.  While a segment is
connected to the process, the SDW access fields will match these KST values.
When the segment is not connected,
.ifi hit "K|access modes~at segment connection"
it is the KST values that are kept up to date.  Any request for the
.ifi hit "K|fs_modes"
access modes of an initiated segment (via dc_find or via fs_modes, the ring
zero internal mode lookup routine) will recompute the KST access fields if
necessary.  If the process' access was changed to the segment, then the dtem
within the KST entry will not match that in the branch because of the previous
call to change_dtem.  The access will be recomputed by
.ifi hit "K|update_kste_access"
calling update_kste_access.  The next connection (segment fault) made to this
segment will copy these values
.ifi hit "K|access modes~in KST"
.ifi hit "K|access modes~in SDW"
into the SDW.  (Since the SDW fields are updated only at seg_fault time, it is
.ifi hit "K|audit~access at connection"
possible to accurately audit the access a process has to a segment by watching
the setting of the SDW access fields.)

     The authorization access of each directory within an address space is
.ifi hit "K|access modes~recomputation"
also maintained within the KST entry for the directory.  Changing the dtem for
a directory's directory entry is the equivalent of calling setfaults for a
segment.  Before looking at the access field for the directory in the KST
entry, dc_find will check to see if the dtem of the directory matches the dtem
of the directory when this access computation was made (as recorded in the KST
entry).  If it does not, the access is recomputed with update_kste_access.
Since any file system operation upon a directory or entry is done with the
directory locked (but refer to directory relocking strategy under file system
mechanisms), it is not necessary to have a literal equivalent to setfaults for
directories.
.ifi l1h "Access Manipulation"
     The access control information pertenent to the three access control
.ifi hit "K|access modes~manipulation"
mechanisms are maintained by three separate programs.  ringbr_ changes the
.ifi hit "K|acl"
.ifi hit "K|asd_"
.ifi hit "K|ringbr_"
.ifi hit "K|reclassify"
.ifi hit "K|ACL"
.ifi hit "K|AIM"
.ifi hit "K|ring brackets"
ring brackets.  acl and asd_ (old and new style primitives) change the ACL.
reclassify changes the access class.  These programs are described under the
file system primitives, and under file system mechanisms.
.ifi l1h "AIM File System Privilege"
     The system maintains the notion of AIM privileges.  These are set via a
.ifi hit "S|AIM privilege~see privilege, AIM"
.ifi hit "K|privilege~AIM"
call to the system_privilege_ gate.  The enabling of a certain AIM privilege
causes the system to ignore AIM considerations relative to the software
mechanisms that would relate to that privilege.  There are two AIM privileges
or interest to the file system, seg and dir privilege.  These privileges are
enabled and disabled by the program set_privileges.

     Enabling seg privilege causes the raw and authorization access modes to
.ifi hit "K|privilege~seg"
all segments to be the same for the process.  That is, the process can read or
write any segment independent of access class.  For this to work, as a start,
access_mode recognizes the seg privilege.  Also, when seg privilege is enabled
(or disabled), all segments within the process have the dtem field in their
KST entries set and the segments themselves setfaulted (within the
.ifi hit "K|access modes~recomputation"
process), so that access will be recomputed, as described above.

     A softer version of seg privilege, that applies to a single segment, is
.ifi hit "K|privilege~initiation"
to privilege initiate the segment (system_privilege_$initiate).  When a
segment is privilege initiated, this fact is recorded in the KST entry for the
segment.  This flag is factored into access computations with respect to the
segment.  The presence of the privilege initiated flag is also considered by
the truncate function.  By the way, enabling seg privilege will not setfault
segments already privilege initiated.

     The dir privilege causes the raw and authorization access modes for all
.ifi hit "K|privilege~dir"
directories to be the same for the process.  That is, the process can operate
on any directory regardless of access class.  The dir privilege flag is
respected by access_mode.  Enabling (or disabling) dir privilege sets the dtem
field in all directories KST entries to force access to be recomputed, as
described above.
.ifi l1h "Attempted Access Violations Auditing Policy"
     For each attempted access of a property of an object, dc_find (who finds
.ifi hit "K|security policy~attempted access violation"
.ifi hit "K|audit~attempted access violation"
the object) makes a series of access checks.  If the access requirements are
not met, an access violation was attempted.  Attempted access violations are
considered a security auditable event.  The auditing of these events is done
by access_audit_$log_entry_ptr, as invoked by dir_control_error within
dc_find.

     dir_control_error determines the correct security offense.  Not only is
this necessary so that the correct auditing message is generated, but it is
also necessary so as not to release too much information to the user.  After
the correct offense is determined, dir_control_error invokes the security
auditing procedure (access_audit_) if this process has been designated as
requiring such a security audit.

     dc_find will either return an error code describing the point of access
failure (such as "Incorrect access on entry" or "Incorrect access to directory
containing entry") or a code expressing failure to locate the desired entry.
However, the code "Insufficient access to return any information" may have to
be returned if the "name lookup policy" is not satisfied.

     dir_control_error has entrypoints corresponding to the various
circumstances under which an attempted access violation is detected.  
Each entry decides the circumstances under which error_table_$no_info is
returned.

     For the append case, the access violation corresponds to a lack of access
in the directory (name duplication errors are handled by name_existant).
Failure to append is considered a failure to look up the name being appended.
Thus, error_table_$no_info is returned if the user has null access to the
directory into which the object was being appended.

     Failure to get/set an attribute property checks the access on the parent
directory and on the object.  The user gets error_table_$no_info only if the
user has null access on both the entry and the parent.

     The status function is called only for the status_attributes function of
dc_find, in which the user is allowed to see both status and attribute
properties, attribute properties if the user has attribute access and status
properties if the user has status access.  The caller would call the
attributes entry if the user lacked access to see both sets of properties;
dir_control_error knows in this case that the user must have attributes access
but lack status access.  So, error_table_$no_info would not be returned in
this case.

     The name_existant and name_non_existant entries enforce the name lookup
policy as described below.
.ifi l1h "Name Lookup Policy"
     The basic policy regarding the determination of the correct security
.ifi hit "S|security policy~name lookup policy~see name lookup policy"
.ifi hit "K|name lookup policy"
offense (censoring the error code) is that the error code returned to the user
should inform the user of the user's lack of access, but only if the user has
sufficient access to determine the existence of the object.  The user is
allowed to know the existence of any object to which the user's effective
access modes on the object are non-null or to which the user's effective
access modes on the parent are non-null.  Non-null access on the object allows
the user to initiate the object, thus proving its existence.  Possessing "s"
access on the parent allows the listing of the object's name; possessing "m"
access allows affecting the object; possessing "a" access allows attempting to
append another occurrence of the object, thus sensing the existence of the
object.  When the object doesn't exist, the user's effective access modes on
the directory that would have contained the object must be non-null for the
user to be allowed to know of the non-existence.

     When the user lacks the ability to determine the existence of an object,
the returned error code is error_table_$no_info ("Insufficient access to
return any information.").  Otherwise, the user receives the intended error.

     The user must also be returned the error error_table_$no_info if the user
lacks access to determine the user's access to the object (the user lacks
access to the parent's parent).  This is a less restrictive test than the
existence test and so it is not explicitly performed.

     This name lookup error policy also applies when a directory within a
pathname is a segment.  This is considered an attempt to determine the
existence of the segment without access to the segment.

     Applying this name lookup policy to the file system object appending
function means that attempting to append an object is interpreted as an
attempt to determine the existence of the object.  Thus, the user must have
.ifi hit "K|creation"
non-null access to the directory in which the append is being attempted to be
informed of the failure of an append operation.

     The name lookup policy is enforced for attempted access violations by the
name_existant and name_non_existant entrypoints to dir_control_error.
name_existant is called when a name is found, but is not the right type.
Examples are when the name corresponds to a name duplication at append time,
or when a pathname is being found and a component of the pathname is actually
a segment.  The user would be given error_table_$no_info only if the user has
null access on both the parent and against the mis-typed entry.  The
name_non_existant entry is called when the name to be found doesn't exist.
The user sees error_table_$no_info if the user has null access to the
directory that would have contained the name.

     The name lookup policy is enforced for successful accesses by virtue of
passing the required access checks for the operation at hand.  For operations
that have no explicit access check (terminating a segment, for instance), the
dc_find function enforces the name lookup policy by looking for non-null
access on the object or the object's parent.
.ifi l1h "Successful Access Audit Policy"
     Since all access computations within the file system are made by dc_find,
.ifi hit "K|security policy~successful access auditing"
.ifi hit "K|audit~successful access"
dc_find is the obvious place to perform the auditing of successful accesses.
Indeed, once all access checks made by dc_find have been made, dc_find
performs the necessary auditing of the granting of access.  It is important to
note that audit messages are therefore generated at the point of access
granting, not at the point of completion of the operation in question.  This
is done for two reasons.  First, it is better modularization.  It is clearly
better for one module (dc_find) to perform all auditing, especially since it
validated the access.  Second, it is possible that an attempted operation may
fail for some potentially obscure reason.  It is better to audit that the
operation was started (access was granted) than to possibly fail to audit
later when the operation is half done.

     This policy does create one problem: the creation of an entry.  When
.ifi hit "K|audit~object creation"
access is granted for object creation, the object does not yet exist, so the
audit message cannot properly refer to it.  So, object creation is doubly
audited; once when creation access was granted, and a second time when the
object fully comes into existence.
.ifi l1h "Detailed Security Policy"
     This section lists all of the access controlled operations in ring zero
.ifi hit "K|security policy~detailed"
and the access checks performed.
.ifi l2h "Access Mode Restrictions"
     For a segment, any combination of the three access modes ("r", "e" and
.ifi hit "K|access modes~restriction on"
"w") may be given in an ACL term.  Any combination of the three directory
access modes may be given in an ACL term ("s", "m" and "a") except that "m"
may not be given without "s".
.ifi l2h "Gate ACL restrictions"
     There are restrictions that apply to the ACL terms within the ACL for a
.ifi hit "K|ACL~gate restrictions"
.ifi hit "S|ACL~gate restrictions~see also check_gate_acl_"
non-ring 0/1 gate.  In particular, only the user's project and the SysDaemon
project may appear on such gates.  The rule is that the project names within
the ACL terms must be either SysDaemon or the project of the process setting
the ACL terms.  The routine that performs this validation is check_gate_acl_.
.ifi hit "K|check_gate_acl_"
It can be called in two ways; one with an actual ACL, as appears in a
directory, and one with a ACL structure as is supplied to asd_.
.ifi l2h "Directory Contents Getting"
     The access requirements for reading the contents of a directory were
described under contents properties, above.  The dc_find entrypoint used to
perform this type of access is dir_read.  Specific examples of reading the
contents of a directory are given below.
.ifi l3h "Access Class Check"
     The function access_class_check, called via system_privilege_, validates
.ifi hit "K|access_class_check"
the access class fields of the entries in a directory.  To do this, it
internally lists the entries (contents) within the directory and reads the
access class fields.
.ifi l3h "IACL Listing"
     The IACL of a directory are standard contents properties of a directory.
.ifi hit "S|IACL~see properties, IACL"
.ifi hit "K|properties~IACL"
No extra requirements exist for listing the IACL for lower rings.
.ifi l3h "Examining a Sub-tree for Deletion"
     A sub-tree can be deleted by the del_dir_tree function.  Since this
.ifi hit "K|del_dir_tree"
.ifi hit "K|deletion"
function uses delentry to delete objects, it does not enforce particular
requirements for the deletion.  It does, however, internally lists the entries
(contents) of the directory.
.ifi l3h "Directory Entry Listing"
     A process may list the name space (and types) of all objects within a
.ifi hit "K|name list"
.ifi hit "S|name list~see also properties, name list"
directory if it meets the directory contents reading access requirements.
Such a process may also list the link pathnames.
.ifi l3h "Quota Getting"
     The segment and directory quota limit and quota used, as well as the
.ifi hit "K|quota"
time-record product (trp) of a directory, contained in its VTOCE, are
considered to be contents properties of the directory.
.ifi l2h "Directory Contents Setting"
     The access requirements for modifying the contents of a directory were
described under contents properties, above.  The dc_find entrypoint used to
perform this type of access is dir_write.  Specific examples of writing the
contents of a directory are given below.
.ifi l3h "IACL Setting"
     The IACL for a directory can be set if the contents setting access
requirements are met.  The IACL can only be set for rings greater than or
.ifi hit "K|properties~IACL"
equal to the current validation level.
.ifi l2h "Object Contents Setting"
     The access requirements for setting the contents of an object were given
above.  Specific special examples are given below.
.ifi l3h "Bit Count Setting"
     The access requirements for setting the bit count of an object were
explained above.  Note that the bit count of an upgraded directory may not be
.ifi hit "K|properties~bit count"
set (except for ring 1 directories).  Thus, non-ring 1 multi-class MSFs are
not allowed.  The access checking is done by the dc_find entrypoints
obj_bc_write and obj_bc_delta_write.
.ifi l3h "Segment Truncation"
     The process must possess "w" effective access on a segment to truncate it
.ifi hit "K|truncation"
(following the standard access requirements for writing).  Note, though, that
auditing is not done when a truncate is attempted on a segment whose copy
switch is on.  This is because the truncate (write) would have been allowed if
a copy were to be made.  Also, a truncate is allowed of segments that were
privileged initiated (allowing a method for truncating lower ring objects).
The dc_find entrypoint that applies is obj_truncate.
.ifi l2h "Status Property Getting"
     The access requirements for getting a status property of an object were
described above, under the description of status properties.  The dc_find
entrypoint associated with this type of access is obj_status_read.  Specific
accesses of this type are given below.
.ifi l3h "ACL Listing"
     Reading the ACL of an object requires "s" effective access on the
.ifi hit "K|properties~ACL"
containing directory.
.ifi l3h "Name Listing"
     Listing the names of a specific entry (within the status_ or status_long
.ifi hit "K|properties~names"
functions) requires "s" effective access.
.ifi l2h "Status Property Setting"
     The access requirements for setting a status property were explained
above under the description of status properties.  Such accesses require a
call to dc_find$obj_status_write, or dc_find$obj_access_write for changes to
access information.  Specific accesses to which this access model applies
follow.
.ifi l3h "ACL Setting"
     Adding or deleting terms from the ACL of an object is considered to
.ifi hit "K|properties~ACL"
affect a status property of the object.  The validation level must be within
the write (modify) bracket of the object.
.ifi l3h "Ring Bracket Setting"
     Setting the ring brackets of an object has the same importance has
.ifi hit "K|properties~ring brackets"
modifying the ACL.  They are considered a status property when set.  The
validation level must also be within the "w"/"m" bracket of the object.
.ifi l3h "File System Object Renaming"
     The access rules for adding, deleting and renaming objects are the access
.ifi hit "K|renaming"
rules for setting status properties of the object.  The process' validation
level must be within the write (modify) bracket of the object (if a branch).
.ifi l3h "File System Object Deleting"
     To delete an object is considered to change a status property of the
.ifi hit "K|deletion"
object (its existence).  The validation level must also be within the write
(modify) bracket of the target.  (Also, the safety and copy switches of the
object must be off.  If the object is a directory, it must be empty.
Attempting to delete a non-empty upgraded directory is a covert channel
auditable event.)
.ifi l3h "Miscelaneous Properties"
     The properties that are considered as status properties when setting are:
.ifi hit "K|properties~status"
copy switch (validation level must be within "w"/"m" bracket of object);
author and bit count author (no validation level check); date-time dumped,
used, modified and entry modified (no validation level check); volume dump
switches (validation level check applies); safety switch (validation level
check applies); don't null zero page (dnzp) switch (no validation level check
applies); synchronized switch (validation level check applies); max length
(validation level check applies); son's logical volume/rpv only switch (no
validation level check applies).
.ifi l2h "Attribute Property Setting"
     The access requirements for setting an attribute property were explained
above under the description of attributes properties.  The only property that
is viewed as an attribute property when setting is the damaged switch.  No
validation level requirements exist on the target for the damaged switch.
.ifi l2h "Attribute Property Getting"
     The access requirements for getting an attribute property of an object
were described above, under the description of attribute properties.
.ifi l3h "Ring Bracket Getting"
     The ring brackets of an object not (necessarily) within the address space
may be viewed as an attribute property of the object.
.ifi l3h "Miscelaneous Properties"
     The properties considered as attribute properties when getting them are:
date-time entry modified, date-time dumped, date-time used, date-time contents
.ifi hit "K|properties~attribute"
modified, records used, logical volume id, current length, bit count, copy
switch, damaged switch, synchronized switch, ring brackets, UID, object type,
author, bit count author, raw and effective access modes,
security-out-of-service flag, multiple-class switch, entry bound, access
classmaster directory flag, physical volume id, usage count, volume dump
switches, maximum length.
.ifi l2h "File System Object Appending"
     Appending a file system object within a directory requires "a" effective
.ifi hit "K|creation"
access on the directory.  If a branch is being appended, then it must normally
be of the same AIM classification as the parent directory.  It must also have
all of its ring brackets be greater than or equal to the validation level.
There are a few exceptions.  A directory with a specified terminal quota may
be created of a higher access class.  Also, a multi-class segment may be
created but only in ring 1.
.ifi l2h "Initiated Segment Attributes"
     The process is allowed to ask for the ring brackets and current effective
access modes for any branch within the process' address space for which the
.ifi hit "K|properties~initiated segments"
user's access modes are non-null, or for which the user possesses "s"
effective access on the parent directory.  These rules follow from reasoning
what attributes the process could determine by making test references to the
segment.  The pathname of an initiated segment may be requested following the
rules of the name lookup policy.  (This includes returning the pathname of the
current working directory or the search rules.)
.ifi l2h "Link Target Chasing"
     The process can find the target of a set of links if either the process
.ifi hit "K|link target"
has non-null effective access to the directory that does (or would) contain
the target or if the process has non-null effective access to the target.
This is the standard name lookup access policy.
.ifi l2h "Working Directory and Search Rule Setting"
     To set a directory as the current working directory, the process must
either have non-null effective access to the directory or non-null effective
.ifi hit "K|working directory"
.ifi hit "K|search rules"
access on the parent (name lookup policy).  This same rule is followed when
adding a directory to the search rules.
.ifi l2h "Segment Initiation"
     The process is allowed to initiate any segment to which the user
.ifi hit "K|initiation"
possesses non-null effective access.  Refer to the description on segment
activation for details of access revokation.
.ifi l3h "Dynamic Linking"
     The resolution of a dynamic link into a target is a special case of
segment initiation.  Indeed, the dynamic linker's search facility (fs_search)
attempts to initiate the desired named object in each directory in the search
rules.  If the object exists, the normal access checks of segment initiation
.ifi hit "K|dynamic linker"
will be used.  If the segment succeeds in being initiated, this is fine.  If
the segment is found but the user lacks access to the segment, the searching
stops.  If the segment exists but is invisible (according to the name lookup
policy), searching continues.  Also, if the segment doesn't exist in the given
search directory, searching continues.

     The segment will not exist within most (if not all) of the directories
within the search rules.  As such, it is undesirable to apply (i.e., spend cpu
time) enforcing the name lookup policy for each directory.  So, failures to
find a segment within a directory when trying to initiate the segment for the
dynamic linker automatically return error_table_$no_info, even when the user
might possess access to see the non-existence.  Since the dynamic linker is
only interested in cases where the initiate succeeds, this lack of information
(whether the user can see the non-existence) has no affect.  Since dc_find is
passing out less information in this case, not more, there is no security
implication of this optimization.
.ifi l2h "Segment Termination"
     The process may terminate any segment within the address space not known
.ifi hit "K|termination"
in other rings.  The process may terminate any segment by pathname only if the
process has access to see the existence of the segment (name lookup policy).
.ifi l2h "Master Directory Quota Setting"
     Setting the quota on a master directory requires "m" raw access to the
directory.  The validation level must also be within the "m" bracket of the
.ifi hit "K|quota"
directory.  This operation is done within master directory control and has its
own AIM rules enforced by master directory control itself, and the master
directory creation function of append.
.ifi l2h "Quota Moving"
     To move quota between a directory and its parent, the process must have
"m" effective access to the parent and "m" effective access on the directory
itself.  (Actually, the process must have "m" raw access on the directory, the
validation level must also be within the "m" bracket of the directory and the
directory must be of the same access class as the user or be strictly
upgraded.  Lower authorization processes are allowed to give quota to (but not
take it away from) higher authorization directories.  Higher authorization
processes cannot move the quota back.)
.ifi l2h "Object Reclassification"
     Performing a reclassify operation (correcting the access class of an
object) requires "m" raw access on the object's parent directory.  (It is not
.ifi hit "K|reclassify"
meaningful to make an AIM check in this case, since the AIM classification of
the object is in doubt.)
.ifi l2h "Node Reclassification"
     Reclassifying the contents of a directory and the directory itself
requires "m" raw access on the parent of the directory.  This is for the same
reason as for the object reclassification function.  It is also necessary to
have "s" access on the target directory (to be able to list the objects to be
reclassified) and "m" access (to be able to reclassify the objects).  This
"sm" check is also a raw check since the AIM classes are questionable.
.ifi l2h "Volume Retrieving"
     The access checks performed by the volume retriever, before it "copies"
.ifi hit "K|volume retriever"
data into the target segment or directory, are performed within ring zero.
The access requirements are "rw"/"sm" effective access on the target for the
user requesting the retrieval or "sm" effective access on the parent directory
for the user requesting the retrieval.
.ifi l2h "Segment Connection"
     The access modes that a process possesses to a segment are found within
.ifi hit "K|connection"
the segment's SDW within the process.  These access fields are maintained by
segment control within the KST entry, and are copied into the SDW by dc_find.
A segment is not allowed to be added to a process' address space unless the
process possesses non-null effective access to the segment (see segment
initiation, below).  However, it is possible for access to be deleted from the
segment while the process has the segment initiated.  When the user still
possesses some access to the segment but not enough for the machine operation
at hand, the standard fault mechanism will audit the access violation and
return the normal error code to the user.  When the authorization access modes
become null (which required that the segment was previously setfaulted from
the address space), seg_fault (actually, dc_find) will refuse any attempt to
re-activate the segment (for this process).  The seg_fault entry of dc_find
will audit this occurrence and determine the user error code.  If the returned
error code is error_table_$no_info, this can be interpreted to mean that the
process lacks access to see the access.  Note, also, that such a seg_fault can
be interpreted as an attempt by the user to determine the state of existence
of the segment.  If the segment was deleted and the process lacks access to
the parent that previously contained it, error_table_$no_info will be
returned.  This censoring of the seg_deleted code from sum follows the name
.ifi hit "S|segment utility module~see sum"
.ifi hit "K|sum"
lookup policy rules applying to the use of sum.  Refer to segment pointer to
entry translation for more details.
.ifi l2h "Gate Definition Getting"
     By normal access rules, the definitions for a gate would not be readable
from the user ring, since the read bracket for a gate would be lower than the
user's ring.  However, it is desirable for the user to be able to read out the
.ifi hit "K|properties~gate definitions"
definitions for a gate; this is not privileged information since the user is
allowed to call the gate (assuming proper access).  So, an obscure function of
dc_find is to allow this.  This is done by translating the user supplied
object pointer (which would have the user's ring in it), into a pointer to the
object within the ring within which the definitions may be read (the read
bracket).  The caller of obj_linkage_ring_ptr (within ring 0) actually reads
the definitions for the user.
.brp


                                          -----------------------------------------------------------


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