I tried out with the examples already available in the code base. Will try
it out on a cluster which I did not have access to today. Will probably
have access tomorrow.

I was not aware of that 'grant' feature which allows to set permission on
all the cells with a specific prefix and on a specific qualifier. I will
check and get back to you on that.

Regards
Ram

On Wed, May 4, 2016 at 10:25 PM, Tokayer, Jason M. <
[email protected]> wrote:

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

Reply via email to