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-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 < > > > > > > > [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. > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
