[
https://issues.apache.org/jira/browse/HBASE-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205035#comment-13205035
]
Enis Soztutar commented on HBASE-5372:
--------------------------------------
Replicating Andrew's comments on the parent issue:
bq. This certainly makes sense for grant/revoke.
bq. However, creating, dropping, or modifying a table has global ramifications
on the cluster. When making changes here it should remain possible to require
global CREATE/ADMIN rights for those actions by policy. This way a site admin
can prevent users from taking actions that perturb region assignment if desired.
Agreed on the possible affects on the global state of the cluster for some
table level operations. If we do change the enforcement to the table level
though, cluster admins can still opt to not give admin rights on the table
level, thus they can prevent possibly disruptive operations. So this change
will only give more flexibility, but will also allow the current setup, where
ADMIN permissions are set only globally.
However, for this maybe we have to revisit table ownership rights. Currently,
the table owner has every right on the table, and this is not managed through
the normal grant/revoke operations, but on the table metadata. We may want to
remove table ownership, but introduce default table creation rights, which
means that when a user creates a table, she automatically get those rights
allocated. But another user can grant extra rights, or revoke them.
> Table mutation operations should check table level rights, not global rights
> -----------------------------------------------------------------------------
>
> Key: HBASE-5372
> URL: https://issues.apache.org/jira/browse/HBASE-5372
> Project: HBase
> Issue Type: Sub-task
> Components: security
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
>
> getUserPermissions(tableName)/grant/revoke and drop/modify table operations
> should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN
> rights. The reasoning is that if a user is able to admin or read from a
> table, she should be able to read the table's permissions. We can choose
> whether we want only READ or ADMIN permissions for getUserPermission(). Since
> we check for global permissions first for table permissions, configuring
> table access using global permissions will continue to work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
