OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
24.1.6 Examples of ACL Checking
The following subsections provide some examples that illustrate ACLs and the access-
check algorithms. The examples use the arbitrary convention of ordering entries as
follows: masks, principals, groups, and ‘‘other’’ entries. However, the access check
algorithm disregards the order in which entries appear in an ACL. Also note that the
permissions in these examples do not refer to any particular permissions implemented by
any ACL manager type.
24.1.6.1 Example 1
Following is an ACL that protects an object to which three principals, janea,
/.../cella/fritzb, and mariac, seek access:
mask_obj:ab
user_obj:abc
user:janea:abdef
foreign_user:/.../cella/fritzb:abc
group:projectx:abcf
group:projecty:bcg
Note: The numbered lists in the discussions that follow correspond to stages 1, 2,
3, 4, 5 and 6 of the access-check algorithm referred to in Section 24.1.5.
The principal janea requests permission c to the object protected by the ACL. Assume
that the principal janea has the privilege attributes of being a member of the groups
projectx and projecty (as well as having a user entry that names her) and that janea is
the principal to which the user_obj entry refers. Assume also that this principal’s
privilege attributes are certified:
1. The user_obj check yields the permissions abc.
The result of this check is that the effective permission set for janea is abc. Because a
matching entry is found during the first stage of access checking, none of the remaining
stages of access checking is executed, even though there are three other matching
entries. The mask_obj entry does not mask the user_obj entry, so janea’s effective
permissions are the permissions in the user_obj entry. Since janea requested a
permission that is a member of the effective permission set, her request is granted.
The second principal seeking access to the protected object is /.../cella/fritzb. This
principal requests permission b. Assume that user_obj resolves to some identity other
than /.../cella/fritzb, and that this principal’s privilege attributes are uncertified:
1. The user_obj check yields no permissions because /.../cella/fritzb’s identity does
not match that of the user_obj (no foreign principal can ever match this entry).
248 Tandem Computers Incorporated 124245