Resolution of an access request
Inheritance begins at the root of the protected object space. Inheritance impacts all objects in the object space until it reaches an object with an explicit ACL policy. At this point, a new chain of inheritance begins.
Objects below an explicitly set ACL policy inherit the new ACL policy. If you delete an explicit ACL policy, permission for all objects reverts to the nearest container object with an explicitly set ACL policy.
When a user tries to access a protected object such as a document, Security Verify Access checks Whether that user has the permissions to access the object. Security Verify Access checks each object along the object hierarchy for the inherited or explicitly set permissions. A user is denied access to an object if any container object in the hierarchy above the protected object does not include the traverse permission for that user. Access is denied if the target object does not contain sufficient permissions to do the requested operation. To succeed an access check, the requester must have both of the following permissions:
- Permission to traverse the path to the requested object
- Appropriate permissions on the requested object
For example, to determine whether a user can read the report.html resource in the /acme/engineering/project_Y/current/ object, Security Verify Access does the following checks:
- Whether traverse permission is set on the root (/).
- Whether traverse permission is set on the acme, engineering, project_Y, and current directories.
- Whether read permission is set on the report.html file.
If any of these checks fail, the user is denied access.
Parent topic: Sparse security policy model