Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 21 May 2014 16:10:42 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12714781.1400251894621.20291.1400688642808@arcas>
In-Reply-To: <JIRA.12714781.1400251894621@arcas>
References: <JIRA.12714781.1400251894621@arcas>
Subject: [jira] [Updated] (HBASE-11194) [AccessController] issue with
 covering permission check in case of concurrent op on same row
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/HBASE-11194?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Purtell updated HBASE-11194:
-----------------------------------

    Fix Version/s:     (was: 0.98.3)
                   0.98.4

Moving to 0.98.4 as this will require new coprocessor hooks or adjusted hoo=
k semantics currently under dev and discussion.

> [AccessController] issue with covering permission check in case of concur=
rent 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.4
>
>
> The issue is the hook where we do check in which we have not acquired row=
lock. Take case of delete, we do the check in the preDelete() hook. We do g=
et the covering cells and check against their acls. At the point of the pre=
Delete hook, we have not acquired the row lock on the deleting row.
> Consider 2 parallel threads one doing put and other delete both dealing w=
ith same row.
> Thread 1 acquired the rowlock and decided the TS  (HRS time) and doing th=
e memstore write and HLog sync but the mvcc read point is NOT advanced.=20
> 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 i=
s no row locking happening at this point. As part of covering permission ch=
eck, it doing a Get. But as said above, the put is not complete and the mvc=
c advance has not happened. So the Get won=E2=80=99t return the new cell.  =
It will return the old cells. And the check pass for the old cells.  Now su=
ppose 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)