HBASE-11432 removed the cell first strategy -Anoop-
On Thu, May 5, 2016 at 4:49 PM, Tokayer, Jason M. <[email protected]> wrote: > Hi Ram, > > I very much appreciate the guidance. I should be able to run through the > gambit of tests via code this afternoon and will report back when I do. > > One thing I don't understand - if I don't do the initial RW grant then userX > will never be allowed to write to the table, so I don't see how I can use > that approach. > > Thanks, > Jason > > > > Sent with Good (www.good.com) > ________________________________ > From: ramkrishna vasudevan <[email protected]> > Sent: Thursday, May 5, 2016 4:03:48 AM > To: [email protected] > Subject: Re: Hbase ACL > > I verified the above behaviour using test case as the cluster was busy with > other activities. > So in the above example that you mentioned, you had already issued RW > access to user-X on the table. Then a specific cell is over written with R > permission using the special 'grant' command. > > Now as per the code since you already have a Write permission granted the > cell level access does not work. Instead if you don't grant the RW > permission to the user-X and try your steps it should work fine. > > So when a user with no permission on a table tries to do some mutations > then if there is already a cell level permission granted by the super user > then the cell level permission takes precedence. > > One thing to note is that the special 'grant' command is only for testing > and not for production use case. You should always go with storing the ACL > per mutation. > > Also see this section > ACL Granularity and Evaluation Order > > ACLs are evaluated from least granular to most granular, and when an ACL is > reached that grants permission, evaluation stops. This means that cell ACLs > do not override ACLs at less granularity. > I will raise a bug to remove the OP_ATTRIBUTE_ACL_STRATEGY from > AccessControlConstants if it is misleading to users. > > Feel free to write back incase am missing something or need further inputs. > Happy to help. > > Regards > Ram > > > > > > On Wed, May 4, 2016 at 11:38 PM, ramkrishna vasudevan < > [email protected]> wrote: > >> I tried out with the examples already available in the code base. Will try >> it out on a cluster which I did not have access to today. Will probably >> have access tomorrow. >> >> I was not aware of that 'grant' feature which allows to set permission on >> all the cells with a specific prefix and on a specific qualifier. I will >> check and get back to you on that. >> >> Regards >> Ram >> >> On Wed, May 4, 2016 at 10:25 PM, Tokayer, Jason M. < >> [email protected]> wrote: >> >>> Hi Ram, >>> >>> Thanks for the reply. I can take a look at that Mutation documentation. >>> But I wanted to first confirm that this works at all, which is why I >>> started in the shell. The docs I’ve been using are here: >>> >>> https://github.com/apache/hbase/blob/master/src/main/asciidoc/_chapters/sec >>> urity.adoc. If you search for 'The syntax for granting cell ACLs uses the >>> following syntax:’ you'll find the example I’ve been following for cell >>> ACLs. According to the docs, "The shell will run a scanner with the given >>> criteria, rewrite the found cells with new ACLs, and store them back to >>> their exact coordinates.”. So I was under the impression that this would >>> lock ALL cells that meet the criteria, and if I wanted to lock a specific >>> cell I could add some more filters. Might I be reading that wrong? >>> >>> I can access the examples and will take a look. Were you able to confirm >>> proper functioning for table overrides on existing cells? >>> >>> -- >>> Warmest Regards, >>> Jason Tokayer, PhD >>> >>> >>> >>> >>> On 5/4/16, 12:30 PM, "ramkrishna vasudevan" >>> <[email protected]> wrote: >>> >>> >Superuser: >>> >grant 'ns1:t1', {'userX' => 'R' }, { COLUMNS => 'cf1', FILTER => >>> >"(PrefixFilter ('r2'))" } >>> > >>> >So you are trying to grant R permission to user-X for a given qualifier. >>> >Please not that this is NOT for a given Cell. >>> > >>> >Reiterating from your first mail >>> >>>What I need to be able to do next is to set user-X’s permissions on a >>> >particular cell to read only and have that take precedence over the table >>> >permissions. >>> >So where is this being done in your above example? I may be missing >>> >something here. >>> > >>> >You need to create Put mutation and set READ permission using the >>> >Mutation.setACL API for User-X for that specific cell. >>> > >>> >Can you see an example in TestCellACLs in case you have access to the >>> >code? >>> > >>> >The idea of cell level ACLs is to give cell level access. So in this case >>> >your super-user can pass a mutation with ACL set on the mutation which >>> >could say - Grant R permission to user-X. >>> > >>> >So only user-X can read the cell but he will not be able to do any >>> updates >>> >to that cell. >>> > >>> >I think once you see some examples in TestCellACLs you can be more clear >>> >on >>> >how it is being done. >>> > >>> >Regards >>> >Ram >>> > >>> > >>> >On Wed, May 4, 2016 at 6:02 PM, Tokayer, Jason M. < >>> >[email protected]> wrote: >>> > >>> >> Hi Ram, >>> >> >>> >> Unfortunately, that configuration doesn’t seem to help. I’ve pasted my >>> >> config followed by the CLI commands I’ve been running so that the issue >>> >> can be reproduced. >>> >> >>> >> >>> >> CONFIG: >>> >> <property> >>> >> <name>hbase.security.authentication</name> >>> >> <value>simple</value> >>> >> </property> >>> >> <property> >>> >> <name>hbase.security.authorization</name> >>> >> <value>true</value> >>> >> </property> >>> >> <property> >>> >> <name>hbase.security.access.early_out</name> >>> >> <value>false</value> >>> >> </property> >>> >> <property> >>> >> <name>hbase.coprocessor.master.classes</name> >>> >> >>> >> >>> >>> >><value>org.apache.hadoop.hbase.security.access.AccessController,org.apach >>> >>e. >>> >> hadoop.hbase.security.visibility.VisibilityController</value> >>> >> </property> >>> >> <property> >>> >> <name>hbase.coprocessor.region.classes</name> >>> >> >>> >> >>> >>> >><value>org.apache.hadoop.hbase.security.access.AccessController,org.apach >>> >>e. >>> >> hadoop.hbase.security.visibility.VisibilityController</value> >>> >> </property> >>> >> <property> >>> >> <name>hbase.coprocessor.regionserver.classes</name> >>> >> >>> >> >>> >>> >><value>org.apache.hadoop.hbase.security.access.AccessController,org.apach >>> >>e. >>> >> >>> >>> >>hadoop.hbase.security.visibility.VisibilityController$VisibilityReplicati >>> >>on >>> >> </value> >>> >> </property> >>> >> >>> >> >>> >> >>> >> CLI COMMANDS: >>> >> >>> >> Superuser: >>> >> create_namespace 'ns1' >>> >> create 'ns1:t1','cf1' >>> >> grant 'userX','RW','ns1:t1' >>> >> >>> >> >>> >> userX: >>> >> put 'ns1:t1', 'r2', 'cf1:q1', 'v1',1462364682267 >>> >> put 'ns1:t1', 'r2', 'cf1:q2', 'v2',1462364700012 >>> >> >>> >> Superuser: >>> >> grant 'ns1:t1', {'userX' => 'R' }, { COLUMNS => 'cf1', FILTER => >>> >> "(PrefixFilter ('r2'))" } >>> >> >>> >> userX: >>> >> put 'ns1:t1', 'r2', 'cf1:q1', 'v2',1462364682267 #WORKS, BUT SHOULD >>> >>IT??? >>> >> >>> >> >>> >> >>> >> Any help/guidance you can provide will be greatly appreciated. >>> >> >>> >> -- >>> >> Warmest Regards, >>> >> Jason Tokayer, PhD >>> >> >>> >> >>> >> >>> >> On 5/3/16, 2:30 PM, "ramkrishna vasudevan" >>> >> <[email protected]> wrote: >>> >> >>> >> >I think reading the code - there should be no change between the >>> >>version >>> >> >that you are using and the trunk version. >>> >> > >>> >> >Set this property to false >>> >> >'hbase.security.access.early_out' and try once. >>> >> >Tomorrow early in the morning I will try out some test case and will >>> >> >revert >>> >> >back to you. >>> >> >Do let me know if the above config works for you. >>> >> > >>> >> >Regards >>> >> >Ram >>> >> > >>> >> >On Tue, May 3, 2016 at 11:27 PM, Tokayer, Jason M. < >>> >> >[email protected]> wrote: >>> >> > >>> >> >> Hi Ram, >>> >> >> >>> >> >> We are using 1.1.2, but can update to most recent if the desired >>> >>feature >>> >> >> is provided. We do set authorization to true, and I can confirm that >>> >>I >>> >> >>can >>> >> >> block writes to the entire table for user-X. But, it that when I >>> >>grant >>> >> >>RW >>> >> >> permission (to user-X) on a table and R only on a specific cell in >>> >>that >>> >> >> table then user-X can still write to that cell. This indicates to me >>> >> >>that >>> >> >> table/cf ACLs are given preference over cell ACLs. >>> >> >> >>> >> >> Have there been significant upgrades to this particular feature >>> since >>> >> >> v1.1.2? Would you recommend attempting an upgrade, or do you think >>> >>the >>> >> >> issue is still present in trunk? Can you verify via tests that >>> >> >> CHECK_CELL_DEFAULT is (a) used by default and (b) is working >>> >>properly? I >>> >> >> don¹t see any unit tests in the codebase for this feature. >>> >> >> >>> >> >> -- >>> >> >> Warmest Regards, >>> >> >> Jason Tokayer, PhD >>> >> >> >>> >> >> >>> >> >> >>> >> >> On 5/3/16, 1:41 PM, "ramkrishna vasudevan" >>> >> >> <[email protected]> wrote: >>> >> >> >>> >> >> >Hi Jason >>> >> >> >Which version of HBase are you using? >>> >> >> > >>> >> >> >Atleast in trunk I could see that >>> >> >>'OP_ATTRIBUTE_ACL_STRATEGY_CELL_FIRST' >>> >> >> >is >>> >> >> >not used rather by default CHECK_CELL_DEFAULT strategy is what >>> >>getting >>> >> >> >used >>> >> >> >now. >>> >> >> > >>> >> >> >Ensure that 'hbase.security.authorization' is set to true in >>> >> >> >hbase-site.xml. If you could tell the version you are using can be >>> >>much >>> >> >> >more specific. >>> >> >> > >>> >> >> >Regards >>> >> >> >Ram >>> >> >> > >>> >> >> >On Tue, May 3, 2016 at 6:22 PM, Tokayer, Jason M. < >>> >> >> >[email protected]> wrote: >>> >> >> > >>> >> >> >> I am working on Hbase ACLs in order to lock a particular cell >>> >>value >>> >> >>for >>> >> >> >> writes by a user for an indefinite amount of time. This same user >>> >> >>will >>> >> >> >>be >>> >> >> >> writing to Hbase during normal program execution, and he needs to >>> >>be >>> >> >> >>able >>> >> >> >> to continue to write to other cells during the single cell lock >>> >> >>period. >>> >> >> >> I¹ve been experimenting with simple authentication (i.e. No >>> >> >>Kerberos), >>> >> >> >>and >>> >> >> >> the plan is to extend to a Kerberized cluster once I get this >>> >> >>working. >>> >> >> >> >>> >> >> >> First, I am able to grant Œuser-X¹ read and write permissions to >>> a >>> >> >> >> particular namespace. In this way user-X can write to any Hbase >>> >> >>table in >>> >> >> >> that namespace during normal execution. What I need to be able to >>> >>do >>> >> >> >>next >>> >> >> >> is to set user-X¹s permissions on a particular cell to read only >>> >>and >>> >> >> >>have >>> >> >> >> that take precedence over the table permissions. I found a >>> >>parameter >>> >> >>in >>> >> >> >>the >>> >> >> >> codebase here >>> >> >> >> >>> >> >> >> >>> >> >> >>> >> >> >>> >> >>> >> >>> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/or >>> >> >> >>g/apache/hadoop/hbase/security/access/AccessControlConstants.java, >>> >> >> >> namely OP_ATTRIBUTE_ACL_STRATEGY_CELL_FIRST, that seems to allow >>> >>for >>> >> >> >>this >>> >> >> >> prioritization of cell-level over table-/column-level. But I >>> >>cannot >>> >> >> >>figure >>> >> >> >> out how to set this with key OP_ATTRIBUTE_ACL_STRATEGY. Is it >>> >> >>possible >>> >> >> >>to >>> >> >> >> set the strategy to cell-level prioritization, preferably in >>> >> >> >> hbase-site.xml? This feature is critical to our cell-level access >>> >> >> >>control. >>> >> >> >> >>> >> >> >> -- >>> >> >> >> *Warmest Regards,* >>> >> >> >> *Jason Tokayer, PhD* >>> >> >> >> >>> >> >> >> ------------------------------ >>> >> >> >> >>> >> >> >> The information contained in this e-mail is confidential and/or >>> >> >> >> proprietary to Capital One and/or its affiliates and may only be >>> >>used >>> >> >> >> solely in performance of work or services for Capital One. The >>> >> >> >>information >>> >> >> >> transmitted herewith is intended only for use by the individual >>> or >>> >> >> >>entity >>> >> >> >> to which it is addressed. If the reader of this message is not >>> the >>> >> >> >>intended >>> >> >> >> recipient, you are hereby notified that any review, >>> >>retransmission, >>> >> >> >> dissemination, distribution, copying or other use of, or taking >>> of >>> >> >>any >>> >> >> >> action in reliance upon this information is strictly prohibited. >>> >>If >>> >> >>you >>> >> >> >> have received this communication in error, please contact the >>> >>sender >>> >> >>and >>> >> >> >> delete the material from your computer. >>> >> >> >> >>> >> >> >>> >> >> ________________________________________________________ >>> >> >> >>> >> >> The information contained in this e-mail is confidential and/or >>> >> >> proprietary to Capital One and/or its affiliates and may only be >>> used >>> >> >> solely in performance of work or services for Capital One. The >>> >> >>information >>> >> >> transmitted herewith is intended only for use by the individual or >>> >> >>entity >>> >> >> to which it is addressed. If the reader of this message is not the >>> >> >>intended >>> >> >> recipient, you are hereby notified that any review, retransmission, >>> >> >> dissemination, distribution, copying or other use of, or taking of >>> >>any >>> >> >> action in reliance upon this information is strictly prohibited. If >>> >>you >>> >> >> have received this communication in error, please contact the sender >>> >>and >>> >> >> delete the material from your computer. >>> >> >> >>> >> >> >>> >> >>> >> ________________________________________________________ >>> >> >>> >> The information contained in this e-mail is confidential and/or >>> >> proprietary to Capital One and/or its affiliates and may only be used >>> >> solely in performance of work or services for Capital One. The >>> >>information >>> >> transmitted herewith is intended only for use by the individual or >>> >>entity >>> >> to which it is addressed. If the reader of this message is not the >>> >>intended >>> >> recipient, you are hereby notified that any review, retransmission, >>> >> dissemination, distribution, copying or other use of, or taking of any >>> >> action in reliance upon this information is strictly prohibited. If you >>> >> have received this communication in error, please contact the sender >>> and >>> >> delete the material from your computer. >>> >> >>> >>> ________________________________________________________ >>> >>> The information contained in this e-mail is confidential and/or >>> proprietary to Capital One and/or its affiliates and may only be used >>> solely in performance of work or services for Capital One. The information >>> transmitted herewith is intended only for use by the individual or entity >>> to which it is addressed. If the reader of this message is not the intended >>> recipient, you are hereby notified that any review, retransmission, >>> dissemination, distribution, copying or other use of, or taking of any >>> action in reliance upon this information is strictly prohibited. If you >>> have received this communication in error, please contact the sender and >>> delete the material from your computer. >>> >> >> > ________________________________________________________ > > The information contained in this e-mail is confidential and/or proprietary > to Capital One and/or its affiliates and may only be used solely in > performance of work or services for Capital One. The information transmitted > herewith is intended only for use by the individual or entity to which it is > addressed. If the reader of this message is not the intended recipient, you > are hereby notified that any review, retransmission, dissemination, > distribution, copying or other use of, or taking of any action in reliance > upon this information is strictly prohibited. If you have received this > communication in error, please contact the sender and delete the material > from your computer.
