Following is the ACL for an object to which one principal, silviob seeks access.
unauthenticated:a
user:jeand:abcde
user:denisf:-
group:projectx:abcd
foreign_other:/.../cella:-
foreign_other:/.../cellc:abc
any_other:ab
Note: The user entry for denisf and the foreign_other entry for cella both specify an empty permission set with the notation - (dash), meaning that identities corresponding to these entries are explicitly denied all permissions. Also, 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 silviob requests permission a. Assume that this principal's privileges include membership in the group projecty and that they are not certified:
1. There is no user_obj entry, so this check can yield no permissions.
2. There is no user entry for this principal, so this check yields no permissions.
3. There is no entry for the group projecty, so this check yields no permissions.
4. There is no other_obj entry, so this check can yield no permissions.
5. The principal is local, so no foreign_other entry can be a match; this check yields no permissions.
6. Having failed to match any entry examined in the preceding checks, the principal matches the any_other entry, which yields the permission set ab. There is no mask_obj entry, but there is the unauthenticated mask entry, which specifies the permission set a. Applying the unauthenticated mask to this privilege attribute entry yields the effective permission a.
The permission requested (a) is a member of the effective permission set (a), so this principal's request is granted.