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 <[email protected]>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 <[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. > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
