Following is the ACL for an object to which two principals, ugob and /.../cellb/lolad, seek access:
mask_obj:bcde
unauthenticated:ab
user_obj:abcdef
user:ugob:abcdefg
group:projectz:abh
foreign_other:/.../cellb/:abc
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 ugob requests permission b. Assume that ugob is not the principal to which the user_obj entry refers. Assume also that the privilege attributes of ugob include membership in the group projectz, in addition to the user entry that names him. In this case, the principal has failed to acquire certified privilege attributes:
1. The user_obj check yields no permissions.
2. The matching entry among the user entries specifies the permissions abcdefg. Applying mask_obj (bcde) yields the permission set bcde. Applying the unauthenticated mask (ab) to the permission set bcde yields the effective permission set b.
Since the principal ugob requests a permission (b) that is a member of the effective permissions set, this principal's request is granted.
A case that illustrates how access is determined for otherwise undifferentiated members of a specified foreign cell is that of the principal /.../cellb/lolad, who requests permission e. Assume that the privilege attributes of this principal are certified:
1. The principal is foreign, so the user_obj check cannot be a match.
2. There are no foreign_user entries.
3. There are no foreign_group entries.
4. The principal lolad is a member of cellb, meaning that the privilege attributes match those in the foreign_other entry for cellb. The permissions specified by the foreign_other entry for cellb (abc) as masked by mask_obj (bcde) yields the effective permission set bc.
The permission requested (e) is not a member of the effective permission set (bc), so the request is denied.