-Re: enable/disable table permission
Gary Helmling 2014-02-26, 00:30
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
* 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:
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.
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: