Grant/Revoke rules

[s8sato]

In the current default permission system, Grant and Revoke instructions follow a single rule: users can only grant or revoke permissions they already possess.

While granting is straightforward, revoking introduces a subtle issue: A user can lose a permission if they grant it to others and then have it revoked by one of those recipients.

Possible Solution

One potential approach is to consider the hierarchical structure of the permission set. For example, revocation could be allowed only if the revoker’s aggregate permission set is greater than that of the target account. This approach could be implemented with the support of #5355, which enables permission aggregation.

Next Steps

Further research is required to refine the Grant/Revoke system design.

[s8sato]

For revoke,

Reference

• revoke statement, ISO/IEC 9075-2, pp.595-610

Possible Design

Implement the following aspects of revoke statement:

• revoke option extension: GRANT OPTION FOR
• drop behavior: CASCADE | RESTRICT

Requirements?

• Should we distinguish between the base permission and the grantable permission?
• Store the inheritance graph from granters to grantees, ensuring that only the granter can revoke the grantee's permissions or roles.
• Should we allow specifying CASCADE or RESTRICT at revoke time?