Permissions

Syntax

GRANT/DENY/REVOKE
CREATE [USER | PRIVILEGE] name WITH [propertyAssignments];
ALTER USER name SET [propertyAssignments];

[CREATE | ALTER | DROP] [USER_GROUP | NAMESPACE_GROUP | ROLE] name [SET | ADD | REMOVE] name1, name2;

[GRANT | DENY | REVOKE] PRIVILEGE create_feature ON [ALL NAMESPACES | NAMESPACE finance] [TO | FROM] bob@glovoapp.com;

SHOW PERMISSIONS WHERE namespace LIKE ‘fm.finance.%’;
(same syntax as SHOW FEATURES)

• USER_GROUP is a set of USERs
• ROLE is a set of PRIVILEGEs
• Org ADMIN privilege has all rights. It cannot be REVOKED or DENied of any rights on any namespace.
• Namespace ADMIN privilege can be REVOKED by Org ADMIN or any users that have the “revoke admin” privilege on this namespace.
• By default, anyone has the ROLE PUBLIC on any namespace. ROLE PUBLIC can include the privilege of removing some privilege from ROLE PUBLIC on a namespace. In that case, first arrived, first being able to set themselves as only admin on a namespace.
• REVOKE vs DENY: DENY creates a new permission, whereas REVOKE deletes a previously set permission (with DENY or GRANT). If REVOKE does not delete anything (because such permission does not exist at this granularity), an error is raised.

Example:

1. GRANT privilege P to User A on Namespace X
2. DENY privilege P to User A on Namespace X (creates a new, overriding permission)
3. REVOKE DENY privilege P from User A on Namespace X (removes the DENY from step 2)
4. REVOKE GRANT privilege P from User A on Namespace X (removes the original GRANT from step 1)
5. REVOKE DENY privilege P from User A on Namespace X (raises an error, as no such DENY exists anymore)

Entities

Org = Project_ID

• Privilege (=equivalent to “action”)
• Role (=equivalent to a “PrivilegeSets”)
• Namespace (=equivalent to “resource”)
• Namespace_Group (=NamespaceSets)
• User
• User_Group (=equivalent to a “team”)

A Permission is a 4-uplet of:

• One Privilege (or Role),
• One Namespace (or Namespace_Group),
• One User (or User_Group)
• GRANT or DENY

Rules

Privileges must be:

• positive: An privilege “opens the possibility to do this action”. To prevent a user from doing sth, we should DENY the positive privilege.
• not overlapping: One GRANT on one privilege should never conflict with one DENY on another privilege.
• Sets can include other sets.
• Hierarchical namespaces: Users having the right on fm.namespace have the same rights on all the descendants (except DENied).

How to resolve conflict?

Most specific first: Permission on one specific user/namespace overwrites permission on a set they belong to, considering the specificity on user first (vs namespace). In doubt, choose DENY.

Example:

Given:

• User A is part of UserSet X
• Namespace B is part of NamespaceSet Y

1. GRANT privilege P to UserSet X on NamespaceSet Y
2. DENY privilege P to User A on NamespaceSet Y
3. GRANT privilege P to UserSet X on Namespace B

Result: User A is denied privilege P on Namespace B, because the user-specific DENY (2) takes precedence over both the less specific GRANT (1) and the namespace-specific GRANT (3).