Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates
 209.85.160.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJDd8GHf7Uc5LTWp_nnXbNFje17W8BmR2uJPC8B1-XqgKw8vHA@mail.gmail.com>
References: 
 <CAJDd8GG7WjZbet+MY2pU+R8AYjJpmetDUZXHAEk0YG-UaRdhBQ@mail.gmail.com>
	<CALte62wKhZSZ46T3mAsWpj8=JuOsFgao2BKXE5GZeasMs-PhoA@mail.gmail.com>
	<CAJDd8GHEUhhg=zX=a=_JS6=QLhH3YNazBP4hhQx-t6_URbF=RA@mail.gmail.com>
	<CAJDd8GHVv3KeuZPr2UhyMAa+itcWnLsRz7sA3N+Guw22QgDaSg@mail.gmail.com>
	<CADfYSXQv05c0MzH1TLevsODkVpOn5eGxhOHnqTQp8SMfvKtAUA@mail.gmail.com>
	<CAJDd8GHf7Uc5LTWp_nnXbNFje17W8BmR2uJPC8B1-XqgKw8vHA@mail.gmail.com>
Date: Wed, 26 Feb 2014 09:00:21 -0800
Message-ID: 
 <CALte62wLtD70N4cPhg3sFcP=SN5SfOQ7-ETnV9PMre=HS8vOZw@mail.gmail.com>
Subject: Re: enable/disable table permission
From: Ted Yu <yuzhihong@gmail.com>
To: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=20cf3011dba9dbb01c04f3522366

--20cf3011dba9dbb01c04f3522366
Content-Type: text/plain; charset=ISO-8859-1

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

--20cf3011dba9dbb01c04f3522366--