The basic model used for access checking is to iterate through a sequence of ACL privilege attribute entries for each member of the requested permissions set, looking for the first match with a privilege attribute (and possibly ANDing the result with the appropriate ACL mask entries (mask_obj and unauthenticated). Entry types are checked in essentially the following order:
· [user_obj]
· user
· foreign_user
· [group_obj], group, foreign_group
· other_obj
· foreign_other
· any_other
In actual practice, the bracketed [user_obj] and [group_obj] entry types are ignored by the access checking algorithm implemented by the DCE ACL library. The reasons for this will be explained shortly. The access check is made at the first match, effectively giving precedence to the most specific match. The group entries are unordered so the match is made against the union of all group entries. This precedence allows explicit inclusion and exclusion of permissions depending on whether a more restrictive set of permissions is matched before or after a less restrictive set.
Except for the user_obj and group_obj entry types, the ACL entry types have semantics clearly defined according to the specificity and the cell of the principals referred to. In the local cell, user is the most specific, referring to some specific local principal. The group entry type refers to a specific set of principals. The other_obj type refers to other local principals not accounted for by user and group entries.
The user and group entries are extended to foreign cells by foreign_user and foreign_group. These are user and group identifiers that include a cell name. Strictly speaking, this distinction between the local and foreign cells is not required, since user and group entries implicitly contain global names (that is, the global name of the local cell is implicitly known.) The user and group entries are therefore really an implementation convenience for principals and groups in the local cell.
The other_obj entry is extended by foreign_other, which is a list of cell names.
Finally, principals that do not meet any of the above criteria can be authorized as any_other. The other_obj, any_other, and foreign_other types are distinguished by cells: other_obj applies to the local cell, foreign_obj applies to specified foreign cells, any_other applies to any cell.
The user_obj and group_obj types have less straightforward semantics. They refer to a special principal and group that must be known to the ACL manager "out of band": that is, they cannot be determined from the ACL entry itself. The semantics of the mask_obj, which is applied to everything except the user_obj and other_obj entries, are also complicated. The mask_obj is implemented to permit POSIX ACLs to more or less maintain UNIX semantics for 000 permissions.
In general, the use of user_obj and group_obj is deprecated: they unnecessarily create a special user, thus complicating the otherwise straightforward semantics of ACLs. Unless you are implementing a file system, you probably do not need these types. (The other_obj type is unobjectionable since it has well defined semantics.) Similarly, the use of mask_obj is deprecated because of its awkward semantics.
Thus it is recommended that you use only types from the following subset of entry types:
· user
· group
· other_object
· foreign_user
· foreign_group
· foreign_other
· any_other
These types allow for the most specific to the most general principals, both for local, specific foreign cells, and for unspecified foreign cells.
The DCE ACL library ignores user_obj and group_obj, because there is no generic way to determine the user and group owners of an arbitrary ACL protected object: the semantics of ownership are application-specific. However, since these types are not recommended for general use anyway, their absence should not be a serious limitation for most applications that use the DCE ACL library.