Replies: 2 comments
-
|
Two solutions: We add a new privilege property like GRANT_OPTION I prefer option 2. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Update : #10294 has been resolved, we have added scoped managed grants, which allows users to MANAGE_GRANTS at object level (schema/table/catalog etc..) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Context
Considering the path of migrating from Hive SQL Standard Based Authorization to Gravitino's access control model.
One of the features we rely on in Hive is
WITH GRANT OPTION, which allows a user to delegatethe ability to grant a specific privilege on a specific object to others:
Gravitino has MANAGE_GRANTS as the closest concept, but after reviewing the source code I
found it is fundamentally metalake-wide and cannot be scoped to a catalog, schema, or table:
Privileges.ManageGrants.canBindTo() only returns true for MetadataObject.Type.METALAKE
hasMetadataPrivilegePermission() in JcasbinAuthorizer only checks MANAGE_GRANTS against the metalake object, not the target object's ancestor hierarchy
grantRolesToUser and grantPrivilegesToRole in PermissionOperations have hardcoded
@AuthorizationExpression(expression = "METALAKE::OWNER || METALAKE::MANAGE_GRANTS"), so even if the above were fixed, role assignment still requires metalake-level authority.I also explored object ownership as a workaround — the owner of a parent object (e.g. schema)
can grant privileges on children — but:
Questions:
Is scoped MANAGE_GRANTS something reasonable to support?
Or is there a recommended workaround today beyond centralizing all grant management through metalake admins?
Beta Was this translation helpful? Give feedback.
All reactions