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