hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-11194) [AccessController] issue with covering permission check in case of concurrent op on same row
Date Fri, 16 May 2014 14:53:15 GMT
Anoop Sam John created HBASE-11194:

             Summary: [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

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

View raw message