Permissions Precedence

Permissions precedence is based on evaluation rules.

The permissions rules work as follows:

Scope rule 
When an access control list (ACL) is enabled, any connection request to a metaspace must be associated with a valid space-level permission entry, which implicitly grants access to the metaspace.

If there is no space-level permission, the client’s connection to the controller fails even if authentication is successful. The only exception is when the user cannot be mapped to the group list and the ACL’s default access is grant_all. In other words, any successful connection to a metaspace requires that one or more permissions with a corresponding scope exist in the permissions table.

The minimum permission required on any scope is read, which implies the right to connect to a metaspace.

Denial rule
 A deny_all declaration for a user or group takes ultimate precedence over any other permission declaration that might apply to the same user or group.
Ambiguity rule
 If there are multiple permissions that can be applied to a metaspace or space, then the permissions declaration that explicitly names the metaspace or space takes precedence over any permissions declarations that use a wildcard character (*).
Owner rule
 If there are multiple permissions that can be applied to a user, the permissions declaration that explicitly names the user takes precedence over any permissions declarations applied to a group that the user is a member of.
Order rule 
If after applying the rules there is still more than one permission that applies to the authenticated user’s context, the effective privilege is retrieved from the most recent (lowest) matching permission in the table.