hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: enable/disable table permission
Date Thu, 27 Feb 2014 16:59:03 GMT
Thanks for the verification, Alex.

hbaseuser needs to have ADMIN privilege so that he can grant permission to
other users.

Calrification: HBASE-8409 was integrated into 0.95.2 so it is in 0.96.x

But I agree: HBASE-9206 would be the missing piece that you need.


On Thu, Feb 27, 2014 at 8:23 AM, Alex Nastetsky <anastetsky@spryinc.com>wrote:

> Ted,
>
> Your patch is indeed a one line fix in a ruby script, but HBASE-8409 is
> not. I would have to upgrade to 0.98 to get those changes. Just for fun, I
> applied your changes to my 0.96 install:
>
> [as user anastetsky]
> hbase(main):006:0> grant 'hbaseuser', 'W', '@mydomain'
> 0 row(s) in 0.2290 seconds
>
> [as user hbaseuser]
> hbase(main):001:0> create 'mydomain:papa','fam'
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
>
> [jar:file:/usr/lib/hadoop/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
>
> [jar:file:/usr/lib/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
>
> ERROR: org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient
> permissions for user 'hbaseuser' (global, action=CREATE)
>
> ----
>
>
> By the way, "user_permission" has a similar issue to the ones you fixed for
> "grant" and "revoke" in HBASE-10621.
>
> hbase(main):008:0> user_permission '@mydomain'
> User
> Table,Family,Qualifier:Permission
>
> ERROR: no method 'getUserPermissions' for arguments
>
> (org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.AccessControlService.BlockingStub,org.jruby.java.proxies.ArrayJavaProxy)
> on Java::OrgApacheHadoopHbaseProtobuf::ProtobufUtil
>
> ----
>
> I took a look at the patch in HBASE-8409 and it looks like it only deals
> with permissions about dealing with namespaces themselves, not with how
> dealing with permissions inside of a namespace. Also from the release notes
> of the ticket:
>
> "This patch introduces security privileges to create, alter or drop
> namespaces. When security is enabled only global admin is allowed to do
> such operations. Richer namespace privileges will be introduced in
> HBASE-9206 <https://issues.apache.org/jira/browse/HBASE-9206>."
>
> So permissions to grant users ability to create tables in a namespace is
> not part of HBASE-8409. I guess at this point my hope is for HBASE-9206.
>
> Thanks for the help.
>
>
>
> On Wed, Feb 26, 2014 at 7:19 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>
> > The patch is one line fix in ruby script which you can apply in your
> > cluster.
> >
> > That way you would be able to verify yourself :-)
> >
> >
> > On Wed, Feb 26, 2014 at 3:51 PM, Alex Nastetsky <anastetsky@spryinc.com
> > >wrote:
> >
> > > Thanks. I am unfortunately on 0.96 still, but looking forward to having
> > it
> > > working in 0.98 when we upgrade.
> > >
> > > Just to confirm, you are able to grant W permissions to hrt_1 in
> > namespace
> > > 'ted', and then hrt_1 can create tables in namespace 'ted', but not in
> > > other namespaces?
> > >
> > >
> > > On Wed, Feb 26, 2014 at 6:41 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> > >
> > > > I put up a patch which I have tested locally.
> > > >
> > > >
> > > > On Wed, Feb 26, 2014 at 2:56 PM, Alex Nastetsky <
> > anastetsky@spryinc.com
> > > > >wrote:
> > > >
> > > > > Thanks, I am watching that issue now.
> > > > >
> > > > >
> > > > > On Wed, Feb 26, 2014 at 5:51 PM, Ted Yu <yuzhihong@gmail.com>
> wrote:
> > > > >
> > > > > > I tried that and stumbled into HBASE-10621
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 26, 2014 at 2:48 PM, Alex Nastetsky <
> > > > anastetsky@spryinc.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Thanks Ted.
> > > > > > >
> > > > > > > Can you use user X to grant hrt_1 permission to create
tables
> > just
> > > in
> > > > > the
> > > > > > > 'ted' namespace (but not in the global namespace)?
> > > > > > >
> > > > > > > I want a user to be able to create their own tables, but
not
> drop
> > > the
> > > > > > > tables of other users. If I can't have that, then I would
> settle
> > > for
> > > > > not
> > > > > > > being able to drop the tables in other namespaces.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 26, 2014 at 5:33 PM, Ted Yu <yuzhihong@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > > I created a table 'ted:t1' using user X in a secure
cluster.
> > > > > > > >
> > > > > > > > I then logged in as user hrt_1 and did the following:
> > > > > > > >
> > > > > > > > hbase(main):007:0> user_permission 'ted:t1'
> > > > > > > > User
> > > > > > > > Table,Family,Qualifier:Permission
> > > > > > > >
> > > > > > > > ERROR:
> org.apache.hadoop.hbase.security.AccessDeniedException:
> > > > > > > Insufficient
> > > > > > > > permissions (user=hrt_1@H.NET, scope=ted:t1, family=,
> > > > action=ADMIN)
> > > > > > > > at
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> org.apache.hadoop.hbase.security.access.AccessController.requirePermission(AccessController.java:387)
> > > > > > > > at
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1613)
> > > > > > > >
> > > > > > > > hbase(main):002:0> disable 'ted:t1'
> > > > > > > >
> > > > > > > > ERROR:
> org.apache.hadoop.hbase.security.AccessDeniedException:
> > > > > > > Insufficient
> > > > > > > > permissions (user=hrt_1@HORTON.YGRIDCORE.NET, scope=ted:t1,
> > > > family=,
> > > > > > > > action=CREATE)
> > > > > > > >
> > > > > > > > So your use case is covered.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Feb 26, 2014 at 2:08 PM, Alex Nastetsky <
> > > > > > anastetsky@spryinc.com
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > I haven't looked at the patch, just the ticket
description.
> > > Here
> > > > is
> > > > > > an
> > > > > > > > > excerpt:
> > > > > > > > >
> > > > > > > > > Lets see an example on how privileges work with
namespaces.
> > > > > > > > > > User "Mike" request for a namespace named
"hbase_perf"
> with
> > > the
> > > > > > hbase
> > > > > > > > > > admin.
> > > > > > > > > > whoami: hbase
> > > > > > > > > > hbase shell >> namespace_create 'hbase_perf'
> > > > > > > > > > hbase shell >> grant 'mike', 'W',
'@hbase_perf'
> > > > > > > > > > Mike creates two tables "table20" and "table50"
in the
> > above
> > > > > > > workspace.
> > > > > > > > > > whoami: mike
> > > > > > > > > > hbase shell >> create 'hbase_perf.table20',
'family1'
> > > > > > > > > > hbase shell >> create 'hbase_perf.table50',
'family1'
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Are you saying the ability to grant users permission
to
> > create
> > > > > tables
> > > > > > > in
> > > > > > > > a
> > > > > > > > > namespace is not part of the patch?
> > > > > > > > >
> > > > > > > > > If it's not, then it does not cover my scenario,
as you
> said.
> > > > Which
> > > > > > > would
> > > > > > > > > mean that the hope is for it to be implemented
in
> HBASE-9206,
> > > > which
> > > > > > > > > apparently hasn't been touched in 5 months.
> > > > > > > > >
> > > > > > > > > I can't imagine the scenario for wanting to prevent
other
> > users
> > > > > from
> > > > > > > > > dropping your table is that uncommon. What's
the point of
> > > > > controlling
> > > > > > > who
> > > > > > > > > can Write to your table if anyone can just drop
it?
> > > > > > > > >
> > > > > > > > > On Wed, Feb 26, 2014 at 3:47 PM, Ted Yu <
> yuzhihong@gmail.com
> > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I went over the patch for HBASE-8409 one
more time.
> > > > > > > > > > I don't see a test case covering your scenario.
> > > > > > > > > >
> > > > > > > > > > Cheers
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Wed, Feb 26, 2014 at 9:36 AM, Alex Nastetsky
<
> > > > > > > > anastetsky@spryinc.com
> > > > > > > > > > >wrote:
> > > > > > > > > >
> > > > > > > > > > > Does that indicate to you an abandoned
ticket?
> > > > > > > > > > >
> > > > > > > > > > > I think that HBASE-8409 alone would
satisfy my needs
> > > because
> > > > it
> > > > > > > > > prevents
> > > > > > > > > > > other tenants from dropping and altering
my tables
> (the W
> > > > > > > > permission).
> > > > > > > > > I
> > > > > > > > > > > can live with users with dropping and
altering tables
> of
> > > > other
> > > > > > > users
> > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > > same namespace.
> > > > > > > > > > >
> > > > > > > > > > > Do you have another suggested approach?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Feb 26, 2014 at 12:00 PM, Ted
Yu <
> > > > yuzhihong@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > I was looking at HBASE-9206 :
the last comment was 5
> > > months
> > > > > > ago.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Feb 26, 2014 at 8:57 AM,
Alex Nastetsky <
> > > > > > > > > > anastetsky@spryinc.com
> > > > > > > > > > > > >wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Thanks for all that detail.
Re: updating
> > documentation,
> > > > it
> > > > > > > looks
> > > > > > > > > like
> > > > > > > > > > > > there
> > > > > > > > > > > > > is a ticket for that:
> > > > > > > > > > https://issues.apache.org/jira/browse/HBASE-6192
> > > > > > > > > > > > >
> > > > > > > > > > > > > My specific use case is to
support secure
> > > multi-tenancy.
> > > > It
> > > > > > > looks
> > > > > > > > > > like
> > > > > > > > > > > > > namespaces is the way to
go, and security for them
> > was
> > > > > added
> > > > > > in
> > > > > > > > > > > > >
> https://issues.apache.org/jira/browse/HBASE-8409with
> > > > > > > additional
> > > > > > > > > > > > security
> > > > > > > > > > > > > being added in
> > > > > > > https://issues.apache.org/jira/browse/HBASE-9206.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Feb 25, 2014 at 7:30
PM, Gary Helmling <
> > > > > > > > > ghelmling@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > It looks like how the
CREATE permission is
> applied
> > > > > changed
> > > > > > > with
> > > > > > > > > > > > > HBASE-6188,
> > > > > > > > > > > > > > which removed the concept
of a table owner.
>  Prior
> > to
> > > > > > > > HBASE-6188,
> > > > > > > > > > the
> > > > > > > > > > > > > > disable/enable table
permission checks required
> > > either:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > * ADMIN permission
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > * the user is the table
owner AND has the CREATE
> > > > > permission
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I believe the original
intent here was that if
> you
> > > > > created
> > > > > > a
> > > > > > > > > table,
> > > > > > > > > > > you
> > > > > > > > > > > > > > should be able to disable
and modify it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > After HBASE-6188, the
check in enable/disable
> table
> > > is
> > > > > > simply
> > > > > > > > for
> > > > > > > > > > > > either
> > > > > > > > > > > > > > ADMIN or CREATE permission.
 This seems to be the
> > > best
> > > > > > > > compromise
> > > > > > > > > > on
> > > > > > > > > > > > > > attempting to maintain
some of the previous
> > > semantics.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Andrew Purtell commented
to this in HBASE-6188:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > <quote>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > CREATE -(DDL) CreateTable,
AddColumn,
> DeleteColumn,
> > > > > > > > DeleteTable,
> > > > > > > > > > > > > > ModifyColumn, ModifyTable,
DisableTable,
> > EnableTable
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ADMIN - All of the above
plus Flush, Split,
> Compact
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It's not useful to give
add/delete/modify schema
> > > > > privileges
> > > > > > > > > without
> > > > > > > > > > > > > > enable/disable to have
them take effect. So
> either
> > we
> > > > do
> > > > > > the
> > > > > > > > > above
> > > > > > > > > > or
> > > > > > > > > > > > we
> > > > > > > > > > > > > > get rid of CREATE. I
think the above distinction
> is
> > > > still
> > > > > > > > useful.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Edit: I don't like that
non-ADMIN can do
> > > enable/disable
> > > > > > > table,
> > > > > > > > > > > because
> > > > > > > > > > > > it
> > > > > > > > > > > > > > can really affect the
cluster if the table is
> > large.
> > > > > > However
> > > > > > > I
> > > > > > > > > > think
> > > > > > > > > > > on
> > > > > > > > > > > > > > balance it would be
more confusing than useful to
> > > > remove
> > > > > > > > > > EnableTable
> > > > > > > > > > > > and
> > > > > > > > > > > > > > DisableTable from the
set of operations CREATE
> > > > permission
> > > > > > > > allows
> > > > > > > > > > > until
> > > > > > > > > > > > > > online schema update-in-place
without disable is
> > > always
> > > > > > > > possible.
> > > > > > > > > > > > > > </quote>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > At this point, it may
be useful to discuss if
> we're
> > > at
> > > > > the
> > > > > > > > point
> > > > > > > > > > yet
> > > > > > > > > > > > > where
> > > > > > > > > > > > > > online schema updates
can be reliably done
> without
> > a
> > > > > table
> > > > > > > > > disable.
> > > > > > > > > > >  In
> > > > > > > > > > > > > > this case, it might
make sense to drop
> > disable/enable
> > > > > table
> > > > > > > > from
> > > > > > > > > > > CREATE
> > > > > > > > > > > > > > permission.  Though
we now have backwards
> > > compatibility
> > > > > to
> > > > > > > > > consider
> > > > > > > > > > > as
> > > > > > > > > > > > > > well.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If this could be better
reflected in the security
> > > > > > > > documentation,
> > > > > > > > > > > please
> > > > > > > > > > > > > do
> > > > > > > > > > > > > > open a JIRA describing
how we can make it
> clearer.
> > >  And
> > > > > if
> > > > > > > you
> > > > > > > > > feel
> > > > > > > > > > > up
> > > > > > > > > > > > to
> > > > > > > > > > > > > > it, a patch or updated
text would be even better.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Feb 25, 2014
at 12:30 PM, Alex Nastetsky
> <
> > > > > > > > > > > > anastetsky@spryinc.com
> > > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't really
understand how HBase permission
> is
> > > > > > expected
> > > > > > > to
> > > > > > > > > > work
> > > > > > > > > > > > > then.
> > > > > > > > > > > > > > A
> > > > > > > > > > > > > > > user needs the
Create permission in order to be
> > > able
> > > > to
> > > > > > > > create
> > > > > > > > > > > their
> > > > > > > > > > > > > own
> > > > > > > > > > > > > > > tables. But that
permission also allows them to
> > > > "drop"
> > > > > > and
> > > > > > > > > > "alter"
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > tables created
by others. Even if those
> > operations
> > > > are
> > > > > > set
> > > > > > > up
> > > > > > > > > to
> > > > > > > > > > > only
> > > > > > > > > > > > > > work
> > > > > > > > > > > > > > > when a table is
disabled, the ability to
> disable
> > a
> > > > > table
> > > > > > is
> > > > > > > > > also
> > > > > > > > > > > > given
> > > > > > > > > > > > > by
> > > > > > > > > > > > > > > the Create permission.
What am I missing?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Feb 25,
2014 at 3:25 PM, Alex
> Nastetsky <
> > > > > > > > > > > > > anastetsky@spryinc.com
> > > > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Sounds like
either permission is sufficient.
> > > Either
> > > > > > way,
> > > > > > > > the
> > > > > > > > > > > > > > > documentation
> > > > > > > > > > > > > > > > could be improved.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Feb
25, 2014 at 3:22 PM, Ted Yu <
> > > > > > > > yuzhihong@gmail.com
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >> Here is
related code from AccessController:
> > > > > > > > > > > > > > > >> {code}
> > > > > > > > > > > > > > > >>   public
void
> > > > > > > > > > > > > > > >>
> > > > > > > > >
> preDisableTable(ObserverContext<MasterCoprocessorEnvironment>
> > > > > > > > > > > > > > > >> c, byte[]
tableName)
> > > > > > > > > > > > > > > >> ...
> > > > > > > > > > > > > > > >>     requirePermission("disableTable",
> > tableName,
> > > > > null,
> > > > > > > > null,
> > > > > > > > > > > > > > > Action.ADMIN,
> > > > > > > > > > > > > > > >> Action.CREATE);
> > > > > > > > > > > > > > > >> {code}
> > > > > > > > > > > > > > > >> requirePermission()
iterates through the
> above
> > > > > > > permissions
> > > > > > > > > and
> > > > > > > > > > > > would
> > > > > > > > > > > > > > > >> return
> > > > > > > > > > > > > > > >> error
for the second permission (CREATE) if
> > > > > validation
> > > > > > > > > fails.
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> Cheers
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> On Tue,
Feb 25, 2014 at 12:12 PM, Alex
> > > Nastetsky <
> > > > > > > > > > > > > > > anastetsky@spryinc.com
> > > > > > > > > > > > > > > >> >wrote:
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> > According
to
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://hbase.apache.org/book/hbase.accesscontrol.configuration.html#d2566e5780
> > > > > > > > > > > > > > > >> > ,
> > > > > > > > > > > > > > > >> > the
Enable/Disable operation is controlled
> > by
> > > > the
> > > > > > > Admin
> > > > > > > > > > > > > permission.
> > > > > > > > > > > > > > > >> > However,
it seems to be controlled instead
> > by
> > > > the
> > > > > > > Create
> > > > > > > > > > > > > permission.
> > > > > > > > > > > > > > > Is
> > > > > > > > > > > > > > > >> > this
a bug or a typo in the documentation?
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > hbase(main):002:0>
disable 'foo'
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > ERROR:
> > > > > > > > > > org.apache.hadoop.hbase.security.AccessDeniedException:
> > > > > > > > > > > > > > > >> Insufficient
> > > > > > > > > > > > > > > >> > permissions
(user=anastetsky@SPRY.COM,
> > > > scope=foo,
> > > > > > > > > family=,
> > > > > > > > > > > > > > > >> action=CREATE)
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >> > Thanks
in advance,
> > > > > > > > > > > > > > > >> > Alex.
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message