Priority order to ACL permission

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.

"