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 <ghelml...@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 <anastet...@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 <anastet...@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 <yuzhih...@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 < > > anastet...@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=anastet...@spry.com, scope=foo, family=, > > >> action=CREATE) > > >> > > > >> > Thanks in advance, > > >> > Alex. > > >> > > > >> > > > > > > > > >
