hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-19334) User.runAsLoginUser not work in AccessController because it use a short circuited connection
Date Thu, 23 Nov 2017 18:41:00 GMT

    [ https://issues.apache.org/jira/browse/HBASE-19334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16264685#comment-16264685

Anoop Sam John commented on HBASE-19334:

I believe u added that TODO abt why using List<Put> instead of Put based API before
the changes/cleanup that happened around CP. Previously we had getTable() in CoprocessorEnvironment
which will create a short circuited connection for the table then. So if u see the old code,
u can see that every time the getTable was called, we created new connection and the user
been passed as the current user context from which the CP is getting executed.  So the issue
with the asyn process or not came in.  Now the code is using new getConnection() which reuses
the initial cluster connection (short circuited) in RS.  For this the user is always the super
user who started RS process. Said that the TODO can be fulfilled with out any change as of
now. Just replace put(List) API with put(Put).  I did not test this but I believe this will
Now this raised many Qs
1. In a secure cluster, the getConnection() might not be the correct one to be used by CPs.
 As there is no way to pass the identity. Forget abt the short circuited connection to same
server. Even if the APIs used over the connection is targeting another server, there the user
will be the hbase super user.  The new createConnection() do not have such an issue and that
looks to be the equivalent of the old way. Any way in the doc addendum patch for the other
issue (createCOnnection), I have added a doc to getConnection() API that the user will be
super user. Pls see if we need stronger message, we can add.
2. The original issue of usage of diff APIs based on AsynProcess used or not - We have to
think abt this also.  Because this will be applicable with the new connection created using
createConnection() API. The RpcContext() not getting passed for the one set of APIs will be
an issue at some point.
What do u all think?  [~zghaobac], [~stack]

> User.runAsLoginUser not work in AccessController because it use a short circuited connection
> --------------------------------------------------------------------------------------------
>                 Key: HBASE-19334
>                 URL: https://issues.apache.org/jira/browse/HBASE-19334
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Guanghao Zhang
>            Assignee: Guanghao Zhang
>         Attachments: HBASE-19334.master.001.patch
> The short-circuited connection will bypass the RPC and the RPC context didn't change.
So it still use the old RPC user to write ACL table and User.runAsLoginUser not work.
> AccessController's grant method.
> {code}
>         User.runAsLoginUser(new PrivilegedExceptionAction<Void>() {
>           @Override
>           public Void run() throws Exception {
>             // regionEnv is set at #start. Hopefully not null at this point.
>             try (Table table = regionEnv.getConnection().
>                 getTable(AccessControlLists.ACL_TABLE_NAME)) {
>               AccessControlLists.addUserPermission(regionEnv.getConfiguration(), perm,
>                   request.getMergeExistingPermissions());
>             }
>             return null;
>           }
>         });
> {code}

This message was sent by Atlassian JIRA

View raw message