hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-11194) [AccessController] issue with covering permission check in case of concurrent op on same row
Date Sat, 17 May 2014 14:10:15 GMT

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

Andrew Purtell edited comment on HBASE-11194 at 5/17/14 2:09 PM:
-----------------------------------------------------------------

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 when evaluating grants 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.


was (Author: apurtell):
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)

Mime
View raw message