[jira] [Commented] (HBASE-11194) [AccessController] issue with covering permission check in case of concurrent op on same row

["Andrew Purtell (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-11194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000798#comment-14000798 ] 

Andrew Purtell commented on HBASE-11194:
----------------------------------------

Both the thread doing the Put and the thread doing the Delete in this scenario must have been granted permission already. When deciding if an action is allowed we take the union of permissions found in the permission dominance hierarchy, which is global -> namespace -> table -> cf -> cell. We start checks at the top and work our way down. In this scheme, cell ACLs can grant access if no other level grants, but they don't revoke access. (Complicating note: We can get the effect of a cell ACL revoking access using the cell-first evaluation strategy at Get or Scan time, but this is not relevant for covering calculations for mutations.). 

If access is not granted at the CF or table level for the Delete, but the Put includes a cell ACL that grants, and the Put is not yet visible to the Delete, then the Delete will not be allowed as there is no visible/effective grant.

If access is granted at the CF or table level for the Delete, it doesn't matter what kind of cell ACL the Put has, the Delete is still allowed. The described interaction between the Put and the Delete is expected behavior for concurrent ops executing in different RPC handlers. 

However, certainly "it's complicated" trying to explain it. It's valid to say we don't want cell ACL semantics so difficult to explain or reason about.

HBASE-11126 is a must as this starts as an issue with the coprocessor framework.

> [AccessController] issue with covering permission check in case of concurrent op on same row
> --------------------------------------------------------------------------------------------
>
>                 Key: HBASE-11194
>                 URL: https://issues.apache.org/jira/browse/HBASE-11194
>             Project: HBase
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 0.98.0
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>             Fix For: 0.99.0, 0.98.3
>
>
> The issue is the hook where we do check in which we have not acquired rowlock. Take case of delete, we do the check in the preDelete() hook. We do get the covering cells and check against their acls. At the point of the preDelete hook, we have not acquired the row lock on the deleting row.
> Consider 2 parallel threads one doing put and other delete both dealing with same row.
> Thread 1 acquired the rowlock and decided the TS  (HRS time) and doing the memstore write and HLog sync but the mvcc read point is NOT advanced. 
> Thread 2 at same time, doing the delete of the row (Say with latest TS . The intent is to delete entire row) and in place of preDelete hook. There is no row locking happening at this point. As part of covering permission check, it doing a Get. But as said above, the put is not complete and the mvcc advance has not happened. So the Get won’t return the new cell.  It will return the old cells. And the check pass for the old cells.  Now suppose the new cell ACL is not matching for the deleting user.  But the cell was not read, the check has not happened.  So the ACL check will allow the user  to delete row..  The flow later comes to HRegion#doMiniBatchMutate() and try acquire row lock and by that time the Thread 1 op was over. So it will get lock and will add the delete tombstone.  As a result the cell, for which the deleting user has no acl right, also will get deleted.



--
This message was sent by Atlassian JIRA
(v6.2#6252)