>>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.
So you want one user to be not allowed to write to a single cell or one column (cf:qual)? Do u know all possible column names for this table? -Anoop- On Fri, May 6, 2016 at 11:59 AM, Anoop John <[email protected]> wrote: > 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.
