hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Helmling <ghelml...@gmail.com>
Subject Re: enable/disable table permission
Date Wed, 26 Feb 2014 00:30:22 GMT
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 <anastetsky@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 <anastetsky@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 <yuzhihong@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 <
> anastetsky@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=anastetsky@SPRY.COM, scope=foo, family=,
> >> action=CREATE)
> >> >
> >> > Thanks in advance,
> >> > Alex.
> >> >
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message