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 <[email protected]> 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 <[email protected] > >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 <[email protected]> wrote: > > > > > I put up a patch which I have tested locally. > > > > > > > > > On Wed, Feb 26, 2014 at 2:56 PM, Alex Nastetsky < > [email protected] > > > >wrote: > > > > > > > Thanks, I am watching that issue now. > > > > > > > > > > > > On Wed, Feb 26, 2014 at 5:51 PM, Ted Yu <[email protected]> wrote: > > > > > > > > > I tried that and stumbled into HBASE-10621 > > > > > > > > > > > > > > > On Wed, Feb 26, 2014 at 2:48 PM, Alex Nastetsky < > > > [email protected] > > > > > >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 <[email protected]> > > 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 ([email protected], 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 ([email protected], scope=ted:t1, > > > family=, > > > > > > > action=CREATE) > > > > > > > > > > > > > > So your use case is covered. > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 26, 2014 at 2:08 PM, Alex Nastetsky < > > > > > [email protected] > > > > > > > >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 <[email protected] > > > > > > 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 < > > > > > > > [email protected] > > > > > > > > > >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 < > > > [email protected]> > > > > > > > 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 < > > > > > > > > > [email protected] > > > > > > > > > > > >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 < > > > > > > > > [email protected]> > > > > > > > > > > > > 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 < > > > > > > > > > > > [email protected] > > > > > > > > > > > > > >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 < > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > >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 < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > >> >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 ([email protected], > > > scope=foo, > > > > > > > > family=, > > > > > > > > > > > > > > >> action=CREATE) > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > Thanks in advance, > > > > > > > > > > > > > > >> > Alex. > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
