[
https://issues.apache.org/jira/browse/HBASE-22581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16864016#comment-16864016
]
István Tóth commented on HBASE-22581:
-------------------------------------
I am mostly basing this on the TODO comment in the addUserPermission method:
The grant/revoke calls to the RegionServer execute in two phases: In the first
phase the client calls the regionServer with a grant/revoke RPC call. Then the
RegionServer translates the grant/revoke call into the appropriate put/delete
on {{hbase:acl}}, and and makes another RPC call to RegionServer.
In order for grant/revoke calls to succeed, it is necessary that hbase:acl puts
and deletes are NOT called from the original threads that received the
grant/revoke RPC calls.
I haven't excatly followed why, maybe the put/delete logic doesn't have the
necessary special case handling for the hbase:acl table and table level Admin
permission, maybe there is some other cause. The point is that the put/delete
calls must be handled with no user context (effectively superuser context), and
the thread change achieves this by not propagating the Caller information.
Pre HBASE-21385 the scalar HTable.delete(Delete d) method used an
AsyncProcessTask to call the RegionServer, but it was changed to to an
in-thread in HBASE-21385.
Post -HBASE-21385- the both the scalar HTable.put(Put p) and
HTable.delete(Delete d) methods process the RPC calls in the caller thread,
while the put/delete methods with List<> arguments use AsyncProcessTask to run
the calls on different threads.
Pre -HBASE-21385- removePermissionRecord called HTable.delete(Delete d), but
the HTable.delete(Delete d) method used AsyncProcessTask, and thus the thread
continuity was broken in the HTable.delete(Delete d) call.
Post HBASE-21385 HTable.delete(Delete d) was changed to do the RPC call in
thread, so there was no thread change between the revoke() and the delete() RPC
calls, leading to permission denied.
My patch simply restores the pre HBASE-21385 operation by breaking the thread
continuity by calling HTable.delete(List d) instead of HTable.delete(Delete d).
The grant case works in the same way in both cases, addUserPermission calls
the put(List) method to break thread continuity.
> user with "CREATE" permission can grant, but not revoke permissions on
> created table
> ------------------------------------------------------------------------------------
>
> Key: HBASE-22581
> URL: https://issues.apache.org/jira/browse/HBASE-22581
> Project: HBase
> Issue Type: Bug
> Components: security
> Affects Versions: 2.1.1, 2.1.5, 2.1.6
> Reporter: István Tóth
> Assignee: István Tóth
> Priority: Major
> Attachments: HBASE-22581.branch-2.1.001.patch,
> HBASE-22581.master.001.patch
>
>
> A user that only has global or namespace "CREATE" permission can grant
> permissions to another user on its created table, but cannot revoke them.
> This bug exists on branch-2.1, from 2.1.1
> 2.0, 2.1.0, master, and branch-2.2 are not effected.
> The bug can be triggered via hbase shell:
> {code:java}
> #Start hbase shell as superuse
> #export HADOOP_USER_NAME=hbase
> hbase shell
> grant 'regularUser1', 'C'
> exit
> #Run hbase shell as regularUser1
> #grant, then revoke 'RX' permission to regularUser2
> #export HADOOP_USER_NAME=regularUser1
> hbase shell
> create 'nunuke','nunuke'
> grant 'regularUser2', 'RX', 'nunuke'
> #This will fail on 2.1.1+
> revoke 'regularUser2', 'nunuke'
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
