You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by Alex Nastetsky <an...@spryinc.com> on 2014/02/25 21:12:56 UTC
enable/disable table permission
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.
Re: enable/disable table permission
Posted by Ted Yu <yu...@gmail.com>.
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 <an...@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 <yu...@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 <yu...@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 <yu...@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 <yu...@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.
> > > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
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 <yu...@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 <yu...@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 <yu...@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 <yu...@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.
> > > > > > > > > > > > > > >> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Ted Yu <yu...@gmail.com>.
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 <an...@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 <yu...@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 <yu...@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 <yu...@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 <yu...@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.
> > > > > > > > > > > > > >> >
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
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 <yu...@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 <yu...@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 <yu...@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 <yu...@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.
> > > > > > > > > > > > >> >
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Ted Yu <yu...@gmail.com>.
I put up a patch which I have tested locally.
On Wed, Feb 26, 2014 at 2:56 PM, Alex Nastetsky <an...@spryinc.com>wrote:
> Thanks, I am watching that issue now.
>
>
> On Wed, Feb 26, 2014 at 5:51 PM, Ted Yu <yu...@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 <yu...@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 <yu...@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 <yu...@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.
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
Thanks, I am watching that issue now.
On Wed, Feb 26, 2014 at 5:51 PM, Ted Yu <yu...@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 <yu...@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 <yu...@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 <yu...@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.
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Ted Yu <yu...@gmail.com>.
I tried that and stumbled into HBASE-10621
On Wed, Feb 26, 2014 at 2:48 PM, Alex Nastetsky <an...@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 <yu...@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 <yu...@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 <yu...@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.
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
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 <yu...@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 <yu...@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 <yu...@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.
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Ted Yu <yu...@gmail.com>.
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 <an...@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 <yu...@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 <yu...@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.
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
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 <yu...@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 <yu...@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 <gh...@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 <yu...@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.
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Ted Yu <yu...@gmail.com>.
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 <an...@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 <yu...@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 <gh...@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 <yu...@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.
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
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 <yu...@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 <gh...@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 <yu...@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.
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Ted Yu <yu...@gmail.com>.
I was looking at HBASE-9206 : the last comment was 5 months ago.
On Wed, Feb 26, 2014 at 8:57 AM, Alex Nastetsky <an...@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 <gh...@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 <yu...@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.
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
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 <gh...@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 <yu...@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.
> > >> >
> > >>
> > >
> > >
> >
>
Re: enable/disable table permission
Posted by Gary Helmling <gh...@gmail.com>.
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 <an...@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 <yu...@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.
> >> >
> >>
> >
> >
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
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 <an...@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 <yu...@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.
>> >
>>
>
>
Re: enable/disable table permission
Posted by Alex Nastetsky <an...@spryinc.com>.
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 <yu...@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.
> >
>
Re: enable/disable table permission
Posted by Ted Yu <yu...@gmail.com>.
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 <an...@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.
>