hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Bertozzi <theo.berto...@gmail.com>
Subject Re: CreateTableHandler: postCreateTableHanler coprocessor runs as RemoteRpcUser privileged action.
Date Tue, 05 May 2015 00:59:49 GMT
in the proc-v2 rewrite (1.1), we converted all the coprocessor Handler
calls to use runAsLogin() as it is the same behavior as the
pre/postOperation() call.
should we revert this stuff to don't call runAsUser()? to me the fact that
Handlers were "hbase" user and the others where not were just a bug in the
implementation. for example modify/truncate/... are sync on the master so
they were calling the Handler with the caller user instead of "hbase", so
there were no rule Handlers = hbase, others=calling-user

Matteo


On Mon, May 4, 2015 at 10:11 AM, Andrew Purtell <apurtell@apache.org> wrote:

> I think at this point we can't change the behavior, that would be a
> regression. Could be better documented. We can include advice on using
> User.runAsLoginUser.
> Would you like to file an issue for the documentation improvement?
>
>
> On Mon, May 4, 2015 at 5:14 AM, abhishek kr <abhishek.kr@huawei.com>
> wrote:
>
> > Hi,
> > We have a custom written coprocessor for CreateTableHandler which does
> > some hdfs related stuff in postCreateTableHandler, and it was working
> fine
> > till HBASE-11886 got merged. It seems that post HBASE-11886 merge, our
> > coprocessor code is getting executed with remote rpc user privileges
> > instead of master privileges:
> > //  --START--
> >     this.activeUser.runAs(new PrivilegedExceptionAction<Void>() {
> >           @Override
> >           public Void run() throws Exception {
> >             cpHost.postCreateTableHandler(hTableDescriptor, newRegions);
> >             return null;
> >           }
> >         });
> > // --END--
> >
> > As per HBASE-11886,  these changes were done to handle table ACL related
> > issue ,  however it does this by reducing the default privileges
> > coprocessor runs under.
> > We can get around this by using User.runAsLoginUser in our coprocessor
> > code but I think  by default coprocessors should continue to run with
> > master/region server identity and HBASE-11886 can be handled in some
> other
> > way, for example using InheritedThreadLocal for RequestContext, as
> > suggested in comments by Anoop in HBASE-11886,  pls let us know ur views
> on
> > this, thanks.
> >
> >
> > Regards,
> > Abhishek
> >
> >
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

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