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 Access Checking.
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).
2. The foreign_user entry for /.../cella/fritzb specifies the permissions abc. The application of the mask_obj, which specifies the permissions ab to this permission set, yields the permissions ab. Since the unauthenticated mask entry is missing from the ACL, all permissions for unauthenticated identities are masked, yielding an empty effective permission set.
The result of these checks is that /.../cella/fritzb's request is denied (and would be denied, regardless of the permission requested). In this case, only the first two stages of access checking are executed.
The third principal seeking access is mariac, who requests permission a. Assume that the privilege attributes of mariac are certified, that mariac is not the principal that corresponds to the user_obj entry, and that mariac is a member of the groups projectx and projecty:
1. The user_obj check yields no permissions.
2. There is no matching user entry.
3. The group check finds two matching entries. The permissions associated with projectx (abcf) when masked by the mask_obj entry (ab) yield the permissions ab. The permissions associated with projecty (bcg) when masked by the mask_obj entry yield the permission b. The union of the permission sets ab and b is the set ab.
The effective permission set for mariac is ab and since the requested permission (a) is a member of that set, mariac's request is granted. The remaining stages of access checking are not executed.