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 Wed, 26 Feb 2014 23:51:24 GMT
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-8409
with
> > > > 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