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

Reply via email to