Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <D34F9FC2.CB2A%jason.tokayer@capitalone.com>
References: <D34E173C.CA97%jason.tokayer@capitalone.com>
	<CAAT7MkrxDX_02aMk6R90ygYumxSvAykzNKu-ExZy-x2LH4+g+A@mail.gmail.com>
	<D34E5BC6.CABF%jason.tokayer@capitalone.com>
	<CAAT7MkqQN0RQ2iBrFUr+FPEPPCcVfp76+tQuY=D8-B5rPSogog@mail.gmail.com>
	<D34F6371.CAE8%jason.tokayer@capitalone.com>
	<CAAT7MkqK-br78hHoTjStt5wZSoPZnJRysH6m-cPWL2SX7TkbJw@mail.gmail.com>
	<D34F9FC2.CB2A%jason.tokayer@capitalone.com>
Date: Wed, 4 May 2016 23:38:54 +0530
Message-ID: <CAAT7MkoUm_17ReOi8SbQ4Hx6LvqyxswwONsZqj3oM8-ujH+m-Q@mail.gmail.com>
Subject: Re: Hbase ACL
From: ramkrishna vasudevan <ramkrishna.s.vasudevan@gmail.com>
To: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=14dae93b57d26beeb60532081e9c
archived-at: Wed, 04 May 2016 18:09:08 -0000

--14dae93b57d26beeb60532081e9c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=E2=80=99ve been using are here:
> https://github.com/apache/hbase/blob/master/src/main/asciidoc/_chapters/s=
ec
> urity.adoc. If you search for 'The syntax for granting cell ACLs uses the
> following syntax:=E2=80=99 you'll find the example I=E2=80=99ve been foll=
owing 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.=E2=80=9D. So I was under the impression that thi=
s 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' =3D> 'R' }, { COLUMNS =3D> 'cf1', FILTER =3D>
> >"(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=E2=80=99s permissio=
ns on a
> >particular cell to read only and have that take precedence over the tabl=
e
> >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 cas=
e
> >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 updat=
es
> >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=E2=80=99t seem to help. I=E2=
=80=99ve pasted my
> >> config followed by the CLI commands I=E2=80=99ve 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.apa=
ch
> >>e.
> >> hadoop.hbase.security.visibility.VisibilityController</value>
> >> </property>
> >> <property>
> >>   <name>hbase.coprocessor.region.classes</name>
> >>
> >>
> >><value>org.apache.hadoop.hbase.security.access.AccessController,org.apa=
ch
> >>e.
> >> hadoop.hbase.security.visibility.VisibilityController</value>
> >> </property>
> >> <property>
> >>   <name>hbase.coprocessor.regionserver.classes</name>
> >>
> >>
> >><value>org.apache.hadoop.hbase.security.access.AccessController,org.apa=
ch
> >>e.
> >>
> >>hadoop.hbase.security.visibility.VisibilityController$VisibilityReplica=
ti
> >>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' =3D> 'R' }, { COLUMNS =3D> 'cf1', FILTER =3D>
> >> "(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 tha=
t
> >>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 m=
e
> >> >>that
> >> >> table/cf ACLs are given preference over cell ACLs.
> >> >>
> >> >> Have there been significant upgrades to this particular feature sin=
ce
> >> >> 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=C2=B9t 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 use=
r
> >> >>will
> >> >> >>be
> >> >> >> writing to Hbase during normal program execution, and he needs t=
o
> >>be
> >> >> >>able
> >> >> >> to continue to write to other cells during the single cell lock
> >> >>period.
> >> >> >> I=C2=B9ve 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 =C5=92user-X=C2=B9 read and write perm=
issions 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 t=
o
> >>do
> >> >> >>next
> >> >> >> is to set user-X=C2=B9s 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 acces=
s
> >> >> >>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 t=
he
> >> >> >>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 us=
ed
> >> >> 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 sende=
r
> >>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 yo=
u
> >> have received this communication in error, please contact the sender a=
nd
> >> 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 informatio=
n
> 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 intend=
ed
> 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.
>

--14dae93b57d26beeb60532081e9c--