hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tokayer, Jason M." <Jason.Toka...@capitalone.com>
Subject Re: Hbase ACL
Date Wed, 04 May 2016 16:55:19 GMT
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"
<ramkrishna.s.vasudevan@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"
>> <ramkrishna.s.vasudevan@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"
>> >> <ramkrishna.s.vasudevan@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.
Mime
View raw message