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 22:56:13 GMT
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