[
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
happen.
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,
> table,
> request.getMergeExistingPermissions());
> }
> return null;
> }
> });
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
