Access Control Lists (ACL) in the DTR

Use

An access control list (ACL) defines the privileges principals (these can be an individual user or a user group) have for a particular resource. Technically speaking, an ACL consists of access control entities or ACEs. It also assigns one or more privileges to a principal.

The figure below shows the class diagram of the ACL:

Rules

It is not necessary to define ACLs for all resources. On the other hand, it is possible to define different ACEs for one resource that exclude one another. To solve these conflicts, the permissions are interpreted according to a set of rules that independently apply to all privileges.

The resource path is used to determine the permissions. The permissions do not need to be defined for all resources: a resource of a child hierarchy level inherits all permissions granted to a parent folder, unless permissions are granted to the child resource directly.

Rule 1 - "final" Before All "Children"

A final ACL annuls all other ACLs that have been defined for the child resource.

Note

The following permissions apply:

Resource	Principal	Privileges
/	administrators	grant adminX
/projects	developers	grant read
/projects/java/dev	developers	grant write

Assume that you want to execute an administrative task that requires all members of the developers group not to check in changes to the DTR. To do this, you must deny a write privilege to "/" using final. In addition, the access control list must be declared as final.

Resource	Inheritance	Principal	Privileges
/		developers	deny write

Rule 2 - "ignore inheritance"

This rule allows you to use the attribute "ignore inheritance" to interrupt the inheritance hierarchy. A resource for which an ACL labeled as "ignore inheritance" is defined does not inherit any authorizations from superior folders.

Note

There are two project groups DevelopersA and DevelopersB . All project members of these two groups are also a member of the Developers group. In the directory structure /projects/A/java/dev/project-internal , the following permissions are granted:

Resource	Inheritance	Principal	Privileges
/projects		Developers	grant read
/projects/B/java/dev		DevelopersB	grant write
/projects/A/java/dev		DevelopersA	grant write
/projects/A/java/dev/project-internal	ignore inheritance	DevelopersA	grant read grant write

All members of group Developers can read everything below the /projects directory, except directory /projects/A/java/dev/project-internal: Only members of group DevelopersA have read access to this directory.
All members of group DevelopersA have read and write access to all resources below the /projects/A/java/dev directory.
All members of group DevelopersB have read and write access to all resources below the /projects/B/java/dev directory.

Rule 3 - "Child" Before "Parent"

This rule allows you to refine permissions for child resources.

To the directory structure /projects/java/dev/.../secret/.../confidential, you want to grant the following permissions:

All members of group Developers can read everything below the /projects directory, except the directory secret.

All members of group Developers have write access to all resources below the dev directory, except to the subtree below secret.

Only user User07 can access the subtree below confidential (read and write). But not even this user can access the resources between secret and confidential if he or she is a member of group Developers.

Rule 4 - "user" before "group"

This rule defines the priority for contradicting ACEs defined for the same resource (because this rule is defined after rule 3, it can affect only the same resource). This rule gives the user entry priority over the group entry.

Rule 5 - "deny" before "grant"

If for a privilege there is a grant as well as a deny permission, then deny takes priority. Because this rule is applied after rule 4, it can affect only colliding permissions for the same user or for user groups with a common member.