Access Control Lists (ACL) 

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

The figure below shows the class diagram of the access list:

 

Class diagram of the access list (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 need not 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 – “finalDeny“ Before All “Children“

A privilege set to finalDeny cancels all other ACEs that grant this privilege to this resource or a child of it.

„finalDeny“ enables a system administrator to temporarily set the DTR into a “read-only“ state without having to delete all existing permissions.

Usually, 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, all you need is to deny a write privilege to ”/“ by finalDeny.

Resource	Principal	Privileges
/	developers	finalDeny write

 

Rule 2 – “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:

Resource	Principal	Privileges
/projects	developers	grant read
/projects/java/dev	developers	grant write
/projects/java/dev/.../secret	developers	deny read deny write
/projects/java/dev/.../secret/.../confidential	User07	grant read grant write

·         All members of the developers group are allowed to read everything under the /projects directory, except the secret directory.

·         All members of the developers group have the right to write to all resources under the dev directory, except to the subtree under secret.

·         Only User07 is allowed to access the subtree under confidential (both read and write). But not even this user can access the resources between secret and confidential (if this user is a member of the developer group).

Rule 3 – “User” Before “Group“

This rule defines the priority when conflicting ACEs are defined for the same resource (since this rule is applied after rule 2, its effect is limited to the same resource). The rule prioritizes the user entry over the group entry.

 

·         User X is a member of group A.

·         Group A has the deny write permission for resource /ws/wsdir/myws/com/tssap.

·         User X has grant write permission for the same resource.

In this case, user X is allowed to write to this resource, even though this right is denied to the members of group A.

Rule 4 – ”deny” Before ”grant“

If, for a privilege, both a grant and a deny permission are set, then the deny permission has priority. Since this rule is applied after rule 3, its effect is limited to colliding permissions for the same user or for user groups that share the same member.

·         User X is a member of group A and of group B.

·         Group A has the grant write permission for resource /ws/wsdir/myws/.

·         Group B has the deny write permission for the same resource.

In this case, write access to the resource is denied to user X. However, rule 2 (user before group) still applies.