hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Nastetsky <anastet...@spryinc.com>
Subject Re: enable/disable table permission
Date Wed, 26 Feb 2014 22:08:18 GMT
I haven't looked at the patch, just the ticket description. Here is an
excerpt:

Lets see an example on how privileges work with namespaces.
> User "Mike" request for a namespace named "hbase_perf" with the hbase
> admin.
> whoami: hbase
> hbase shell >> namespace_create 'hbase_perf'
> hbase shell >> grant 'mike', 'W', '@hbase_perf'
> Mike creates two tables "table20" and "table50" in the above workspace.
> whoami: mike
> hbase shell >> create 'hbase_perf.table20', 'family1'
> hbase shell >> create 'hbase_perf.table50', 'family1'


Are you saying the ability to grant users permission to create tables in a
namespace is not part of the patch?

If it's not, then it does not cover my scenario, as you said. Which would
mean that the hope is for it to be implemented in HBASE-9206, which
apparently hasn't been touched in 5 months.

I can't imagine the scenario for wanting to prevent other users from
dropping your table is that uncommon. What's the point of controlling who
can Write to your table if anyone can just drop it?

On Wed, Feb 26, 2014 at 3:47 PM, Ted Yu <yuzhihong@gmail.com> wrote:

> I went over the patch for HBASE-8409 one more time.
> I don't see a test case covering your scenario.
>
> Cheers
>
>
> On Wed, Feb 26, 2014 at 9:36 AM, Alex Nastetsky <anastetsky@spryinc.com
> >wrote:
>
> > Does that indicate to you an abandoned ticket?
> >
> > I think that HBASE-8409 alone would satisfy my needs because it prevents
> > other tenants from dropping and altering my tables (the W permission). I
> > can live with users with dropping and altering tables of other users in
> the
> > same namespace.
> >
> > Do you have another suggested approach?
> >
> >
> > On Wed, Feb 26, 2014 at 12:00 PM, Ted Yu <yuzhihong@gmail.com> wrote:
> >
> > > I was looking at HBASE-9206 : the last comment was 5 months ago.
> > >
> > >
> > > On Wed, Feb 26, 2014 at 8:57 AM, Alex Nastetsky <
> anastetsky@spryinc.com
> > > >wrote:
> > >
> > > > 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 <ghelmling@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 <
> > > 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