hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Nastetsky <anastet...@spryinc.com>
Subject Re: enable/disable table permission
Date Thu, 27 Feb 2014 16:23:23 GMT
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