ACL Evaluation

When a user requests that an operation be performed on an object, the system examines the object's ACL to determine the user's permissions. The system examines the entries in an ACL in the order described in the following list. It stops checking a user's permissions as soon as the user matches a qualification described in the list. Remember as you read the list that the evaluation of a user's permissions progresses to a step only if the user fails to match all previous qualifications.

1. The user owns the object. The system grants the user the permissions specified with the user_obj entry. These permissions are not filtered through the mask_obj.

2. A user or foreign_user entry exists for the user. The system grants the user the permissions specified with that entry after filtering the entry through the mask_obj.

3. The user belongs to the group that owns the object (the owning group's permissions are specified with the group_obj entry) or to any other groups that have group or foreign_group entries. If the evaluation progresses to this step, the user accrues permissions from all of the groups to which he or she belongs. The system filters the permissions accrued from all of the groups to which the user belongs through the mask_obj and grants the user only those permissions found in both the groups and the mask_obj.

4. The user is from the local cell. The system grants the user the permissions specified with the other _obj entry. These permissions are not filtered through the mask_obj.

7-12 any_other entry after filtering the entry through the mask_obj.

After the system matches the user attempting to perform an operation with one of the previous qualifications, it determines whether the user is authenticated. If the user is authenticated, the system grants the user the permissions associated with his or her authenticated identity. Otherwise, the system filters the permissions associated with the identity through the unauthenticated mask and grants the user the permissions that remain after filtering. Because an ACL does not have to contain an entry that applies to a user, if there is no match between the user requesting access to an object name does not have its own entry. If an individual user granted permissions on an object is also granted additional permissions on the object by a group to which he or she belongs, the additional permissions are not recognized because the system evaluates the entry for the individual user first.

For example, suppose the user frost is specifically granted only the read and write permissions on a file. Suppose further that frost is also a member of the group writers, which is granted the read, write, and control permissions on the same file. the group to which frost belongs (the entry with more permissions).

You can use the ACL evaluation routine to extend or restrict the permissions granted to a particular member of a group. For instance, in the DeE User's Guide and Reference

following example, the purchasing group is granted the read, write, and execute permissions on the file named purchasing.memo. If the user terry is a member of that group, you can grant terry more or fewer permissions on the file by including an entry for the user in the ACL for the file.

group:purchasing:rwx---user: terry:

r---The system grants the r, w, and x permissions to every member of the purchasing group except terry. Because it evaluates the more-specific entry (the one for the individual user terry) before it evaluates the less-specific entry (the one for the group purchasing), the system limits terry to just the r permission.

7.3.1 Interaction of ACLs with UNIX Mode Bits

In the UNIX file system, every file and directory object has an associated set of mode bits that provide information about the object. In addition to identifying the type of the object (file or directory), these bits define the permissions granted to the user who owns the object, members of the group that owns the object, and all other system users. These mode bits are referred to as the owner, group, and other mode bits, respectively.

Each class of user (owner, group, and other) can be assigned read (r), write (w), and execute (x) permissions or any combination of the three permissions via the appropriate mode bits. The operations associated with the bits are similar to those associated with the corresponding permissions for DCE ACLs. The settings of the mode bits for any object can be listed with the UNIX Is -I command or its equivalent; they can be set with the UNIX chmod command or its equivalent. Because DCE ACLs work only with DCE LFS data, mode bits are the only form of protection associated with non-LFS data.

When evaluating the ACL entries associated with a DCE LFS object, the system first reads the owner, group, and other mode bits for the object. It then uses these mode bits as the corresponding permissions in the appropriate ACL entries, as follows:

• The owner mode bits supply the r, w, and x permissions for the user_obj entry.

7-14

• The other mode bits supply the r, W, and x permissions for the other_obj entry .

• The group mode bits supply the r, W, and x permIssIons for the mask_obj entry. If the mask_obj entry does not exist, the group mode bits supply the three permissions for the group_obj entry. If the mode bits supply the permissions for the mask_obj entry, they do not affect the group_obj entry, and vice versa.

In effect, the UNIX mode bits override the ACL permissions for these entry types. They have no effect on the other ACL entry types.

For example, suppose a file owned by terry has the following ACL entries:

mask_obj:r--- user_obj:rwxc-- group_obj:r-x---

other_obj:---In this case, the corresponding UNIX mode bits for the file are -rwxr--- 1 terry 3625 Nov 13 18:17 filename

The initial r, W, and x mode bits correspond to the matching permissions of the user_obj entry. The second r mode bit corresponds to the r permission of the mask_obj entry.

To keep an object's mode bits as closely aligned with its DCE ACLs as possible, the system modifies the appropriate mode bits associated with an object whenever you modify an _obj entry (user_obj, mask_obj or group_obj, or other_obj) in the object's ACL. Similarly, it effectively updates an object's ACL when you use the UNIX chmod command to modify the mode bits associated with the object. Thus, an object's mode bits are always kept in agreement with its ACL permissions.

DeE User's Guide and Reference