Priority order to ACL permission

[pnone]

Hello Support,

For a particular project ACL permission, if "everyone" group is added with DENY permission and another group ABCD is added with ALLOW permission, then does the members of ABCD group will have effective permission as ALLOW or DENY?

In essence, what is the priority order to effective project ACL permission.

I am assuming all users of Integrity are always members of "everyone" group unconditionally.

Thank you.

Regards

[KaelLizak]

Hi Pashan None‌,

This depends on the release you are on.  By design, a deny on everyone would override any allow by another group at the same level, however there was a defect in Integrity 10.2 and earlier which would cause specific groups to take precedence over everyone at the same level.  So in ILM 10.2 or earlier, your ABCD group would have allow, but in ILM 10.3 or later, your ABCD group would have deny.

Your assumption about the everyone group is correct.

Regards,
Kael

[pnone]

Hello Kael,

Now suppose a member called MEMBER is within two groups, which are called ALLOW_GROUP and DENY_GROUP.

DENY_GROUP have all the deny permissions and applied at the parent ACL called PARENT_ACL.

ALLOW_GROUP has all the necessary allow permissions and is applied at the CHILD_ACL.

CHILD_ACL is under the PARENT_ACL hierarchy.

What will be the effective permission for MEMBER while he/she is at the CHILD_ACL project contents?

Hope my question is clear.

Thank you.

Regards

[mrump · Accepted solution]

Hi Pashan,

The effeictive permission for the member will be "deny".

Reason:

1. The Permission are both set on "Group Principals", so their "weight" is equal.

2. Given that the Deny is inherited from the PARENT_ACL

3. A DENY can never be turned into a ALLOW by a CHILD_ACL of the same "weight". If you want to do that, you ned to set the ALLOW for a "User-Principal".

HTH Matthias

Quote from the Client Help

"...

Resolution of Permission Conflicts

In cases where a user is identified as a principal with his or her own permissions and is also part of a group that is granted permissions, it is important to understand how any permission conflicts are resolved.

Each ACL entry specifies the set of permissions that are to be allowed (if positive) or denied (if negative). A principal can have at most one positive ACL entry and one negative entry, that is, multiple positive or negative ACL entries for the same permission are not allowed for any principal. All defined permissions take precedence over inherited permissions.

In resolving ACL permissions, any time a permission is explicitly specified for a user principal that permission takes precedence over his or her inclusion in a group. Individual permissions always override permissions of the group(s) the individual belongs to. Therefore, individual negative permissions (specific denial of permissions) override the positive permissions of the group, and individual positive permissions override the negative permissions of the group. For example, a user—Patrick Molinas—is allowed the CreateProject permission through the user principal for pmolinas, but is denied the CreateProject permission through his membership in the group principal for Developers. Because the permissions of the individual principal override the permissions of the group principal, Patrick is allowed the CreateProject permission.

In resolving a conflict between groups, negative permissions take precedence. If a principal is allowed a permission in one group but denied that same permission in another group, the conflict is resolved by denying the permission.

The permission set for the principal is then inherited from the parent ACL. If the root ACL is checked and offers no explicit positive or negative entry to apply to the principal, then the principal is considered to have an empty permission set for the resolved ACL, which in turn defaults to a denied permission.

Key factors for permissions include the following:

• Permissions are always in one of three conditions: allowed, denied, or cleared.
• The server always uses the most specific permission it finds in the ACL hierarchy. For example, the allowed and denied permissions are more specific than a cleared permission.
• Defined permissions take precedence over inherited permissions.
• Based on inheritance, an explicitly denied permission takes precedence, even if that permission is allowed through another principal. When you clear a permission, that permission can still be explicitly allowed through another principal or through a parent ACL.
• A permission that is explicitly specified for a user principal takes precedence over his or her inclusion in a group. A permission assigned to an individual always overrides the permissions of the group the individual belongs to.
• A principal can have at most one positive ACL entry and one negative entry. Multiple positive or negative ACL entries for the same permission are not allowed for any principal.
• If there is no entry for a particular principal, then the principal is considered to have an empty permission set for that ACL. The permission set for the principal is then inherited from the parent ACL.
• In resolving a conflict between groups, negative permissions take precedence. If a principal is allowed a permission in one group but denied that same permission in another group, the conflict is resolved by denying the permission.

"