Hbase ACL

["Tokayer, Jason M." <Ja...@capitalone.com>]

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 herehttps://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/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
[cid:BC8E9BC9-24FF-45A2-9D71-15EEC66C2C79]
________________________________________________________

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.

Re: Hbase ACL

[Anoop John <an...@gmail.com>]

>>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,
Valid Q.. Came to my mind as well.. So the ans is the 1t write of the
cell to be done with a user who is having permission. (super user?)
While doing that write he has to give R and/or W permission to the
specific user..  Then onwards that user can read and/or update that
cell.  So u can consider a per cell W permission as an update
permission. Because one write is needed any way to give this cell
level permission.

As per the above Qs anw, we can help you how you can solve ur business use case.

-Anoop-

On Fri, May 6, 2016 at 12:20 PM, ramkrishna vasudevan
<ra...@gmail.com> wrote:
> Thanks Anoop for pointing to the JIRA.
>>>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,
>
> Even if you don't set a grant permisison to a table for userX - you will be
> able to write and read to the table provided the cell to which you are
> writing / reading is having the specific permission for that userX.
>
> I think in your case it is better that userX is given access to specific
> Qualifier and specific family only if you know the list of qualifiers
> before hand rather than giving permission for the entire table. This way
> you can ensure that your cell level permission takes effect.  I verified
> this with a test case too.
>
> Regards
> Ram
>
> On Fri, May 6, 2016 at 12:14 PM, Anoop John <an...@gmail.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.
>>
>> 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 <an...@gmail.com> wrote:
>> > HBASE-11432 removed the cell first strategy
>> >
>> > -Anoop-
>> >
>> > On Thu, May 5, 2016 at 4:49 PM, Tokayer, Jason M.
>> > <Ja...@capitalone.com> 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 <ra...@gmail.com>
>> >> Sent: Thursday, May 5, 2016 4:03:48 AM
>> >> To: user@hbase.apache.org
>> >> 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 <
>> >> ramkrishna.s.vasudevan@gmail.com> 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. <
>> >>> Jason.Tokayer@capitalone.com> 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"
>> >>>> <ra...@gmail.com> 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. <
>> >>>> >Jason.Tokayer@capitalone.com> 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"
>> >>>> >> <ra...@gmail.com> 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. <
>> >>>> >> >Jason.Tokayer@capitalone.com> 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"
>> >>>> >> >> <ra...@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.Tokayer@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.
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >>
>> >>>> >> ________________________________________________________
>> >>>> >>
>> >>>> >> 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.
>>

Re: Hbase ACL

[ramkrishna vasudevan <ra...@gmail.com>]

Thanks Anoop for pointing to the JIRA.
>>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,

Even if you don't set a grant permisison to a table for userX - you will be
able to write and read to the table provided the cell to which you are
writing / reading is having the specific permission for that userX.

I think in your case it is better that userX is given access to specific
Qualifier and specific family only if you know the list of qualifiers
before hand rather than giving permission for the entire table. This way
you can ensure that your cell level permission takes effect.  I verified
this with a test case too.

Regards
Ram

On Fri, May 6, 2016 at 12:14 PM, Anoop John <an...@gmail.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.
>
> 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 <an...@gmail.com> wrote:
> > HBASE-11432 removed the cell first strategy
> >
> > -Anoop-
> >
> > On Thu, May 5, 2016 at 4:49 PM, Tokayer, Jason M.
> > <Ja...@capitalone.com> 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 <ra...@gmail.com>
> >> Sent: Thursday, May 5, 2016 4:03:48 AM
> >> To: user@hbase.apache.org
> >> 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 <
> >> ramkrishna.s.vasudevan@gmail.com> 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. <
> >>> Jason.Tokayer@capitalone.com> 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"
> >>>> <ra...@gmail.com> 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. <
> >>>> >Jason.Tokayer@capitalone.com> 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"
> >>>> >> <ra...@gmail.com> 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. <
> >>>> >> >Jason.Tokayer@capitalone.com> 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"
> >>>> >> >> <ra...@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.Tokayer@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.
> >>>> >> >>
> >>>> >> >>
> >>>> >>
> >>>> >> ________________________________________________________
> >>>> >>
> >>>> >> 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.
>

Re: Hbase ACL

[Anoop John <an...@gmail.com>]

>>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 <an...@gmail.com> wrote:
> HBASE-11432 removed the cell first strategy
>
> -Anoop-
>
> On Thu, May 5, 2016 at 4:49 PM, Tokayer, Jason M.
> <Ja...@capitalone.com> 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 <ra...@gmail.com>
>> Sent: Thursday, May 5, 2016 4:03:48 AM
>> To: user@hbase.apache.org
>> 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 <
>> ramkrishna.s.vasudevan@gmail.com> 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. <
>>> Jason.Tokayer@capitalone.com> 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"
>>>> <ra...@gmail.com> 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. <
>>>> >Jason.Tokayer@capitalone.com> 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"
>>>> >> <ra...@gmail.com> 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. <
>>>> >> >Jason.Tokayer@capitalone.com> 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"
>>>> >> >> <ra...@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.Tokayer@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.
>>>> >> >>
>>>> >> >>
>>>> >>
>>>> >> ________________________________________________________
>>>> >>
>>>> >> 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.

Re: Hbase ACL

[Anoop John <an...@gmail.com>]

HBASE-11432 removed the cell first strategy

-Anoop-

On Thu, May 5, 2016 at 4:49 PM, Tokayer, Jason M.
<Ja...@capitalone.com> 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 <ra...@gmail.com>
> Sent: Thursday, May 5, 2016 4:03:48 AM
> To: user@hbase.apache.org
> 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 <
> ramkrishna.s.vasudevan@gmail.com> 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. <
>> Jason.Tokayer@capitalone.com> 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"
>>> <ra...@gmail.com> 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. <
>>> >Jason.Tokayer@capitalone.com> 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"
>>> >> <ra...@gmail.com> 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. <
>>> >> >Jason.Tokayer@capitalone.com> 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"
>>> >> >> <ra...@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.Tokayer@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.
>>> >> >>
>>> >> >>
>>> >>
>>> >> ________________________________________________________
>>> >>
>>> >> 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.

RE: Hbase ACL

["Tokayer, Jason M." <Ja...@capitalone.com>]

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 <ra...@gmail.com>
Sent: Thursday, May 5, 2016 4:03:48 AM
To: user@hbase.apache.org
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 <
ramkrishna.s.vasudevan@gmail.com> 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. <
> Jason.Tokayer@capitalone.com> 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"
>> <ra...@gmail.com> 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. <
>> >Jason.Tokayer@capitalone.com> 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"
>> >> <ra...@gmail.com> 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. <
>> >> >Jason.Tokayer@capitalone.com> 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"
>> >> >> <ra...@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.Tokayer@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.
>> >> >>
>> >> >>
>> >>
>> >> ________________________________________________________
>> >>
>> >> 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.

Re: Hbase ACL

[ramkrishna vasudevan <ra...@gmail.com>]

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 <
ramkrishna.s.vasudevan@gmail.com> 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. <
> Jason.Tokayer@capitalone.com> 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"
>> <ra...@gmail.com> 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. <
>> >Jason.Tokayer@capitalone.com> 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"
>> >> <ra...@gmail.com> 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. <
>> >> >Jason.Tokayer@capitalone.com> 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"
>> >> >> <ra...@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.Tokayer@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.
>> >> >>
>> >> >>
>> >>
>> >> ________________________________________________________
>> >>
>> >> 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.
>>
>
>

Re: Hbase ACL

[ramkrishna vasudevan <ra...@gmail.com>]

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. <
Jason.Tokayer@capitalone.com> 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"
> <ra...@gmail.com> 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. <
> >Jason.Tokayer@capitalone.com> 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"
> >> <ra...@gmail.com> 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. <
> >> >Jason.Tokayer@capitalone.com> 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"
> >> >> <ra...@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.Tokayer@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.
> >> >>
> >> >>
> >>
> >> ________________________________________________________
> >>
> >> 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.
>

Re: Hbase ACL

["Tokayer, Jason M." <Ja...@capitalone.com>]

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"
<ra...@gmail.com> 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. <
>Jason.Tokayer@capitalone.com> 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"
>> <ra...@gmail.com> 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. <
>> >Jason.Tokayer@capitalone.com> 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"
>> >> <ra...@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.Tokayer@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.
>> >>
>> >>
>>
>> ________________________________________________________
>>
>> 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.

Re: Hbase ACL

[ramkrishna vasudevan <ra...@gmail.com>]

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. <
Jason.Tokayer@capitalone.com> 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.apache.
> hadoop.hbase.security.visibility.VisibilityController</value>
> </property>
> <property>
>   <name>hbase.coprocessor.region.classes</name>
>
> <value>org.apache.hadoop.hbase.security.access.AccessController,org.apache.
> hadoop.hbase.security.visibility.VisibilityController</value>
> </property>
> <property>
>   <name>hbase.coprocessor.regionserver.classes</name>
>
> <value>org.apache.hadoop.hbase.security.access.AccessController,org.apache.
> hadoop.hbase.security.visibility.VisibilityController$VisibilityReplication
> </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"
> <ra...@gmail.com> 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. <
> >Jason.Tokayer@capitalone.com> 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"
> >> <ra...@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.Tokayer@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.
> >>
> >>
>
> ________________________________________________________
>
> 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.
>

Re: Hbase ACL

["Tokayer, Jason M." <Ja...@capitalone.com>]

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.apache.
hadoop.hbase.security.visibility.VisibilityController</value>
</property>
<property>
  <name>hbase.coprocessor.region.classes</name>
  
<value>org.apache.hadoop.hbase.security.access.AccessController,org.apache.
hadoop.hbase.security.visibility.VisibilityController</value>
</property>
<property>
  <name>hbase.coprocessor.regionserver.classes</name>
  
<value>org.apache.hadoop.hbase.security.access.AccessController,org.apache.
hadoop.hbase.security.visibility.VisibilityController$VisibilityReplication
</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"
<ra...@gmail.com> 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. <
>Jason.Tokayer@capitalone.com> 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"
>> <ra...@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.Tokayer@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.
>>
>>

________________________________________________________

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.

Re: Hbase ACL

[ramkrishna vasudevan <ra...@gmail.com>]

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. <
Jason.Tokayer@capitalone.com> 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"
> <ra...@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.Tokayer@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.
>
>

Re: Hbase ACL

["Tokayer, Jason M." <Ja...@capitalone.com>]

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"
<ra...@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.Tokayer@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.

Re: Hbase ACL

[ramkrishna vasudevan <ra...@gmail.com>]

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.Tokayer@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/org/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.
>