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" <ramkrishna.s.vasude...@gmail.com> 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. < >jason.toka...@capitalone.com> 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.
