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 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)
