[
https://issues.apache.org/jira/browse/HBASE-15132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15113449#comment-15113449
]
Enis Soztutar commented on HBASE-15132:
---------------------------------------
bq. I don't think so.
bq. Here is the stack trace:
The stack trace will not contain the User.doAs() necessarily. We find the
request user like this:
{code}
private User getActiveUser() throws IOException {
User user = RpcServer.getRequestUser();
if (user == null) {
// for non-rpc handling, fallback to system user
user = userProvider.getCurrent();
}
return user;
}
{code}
So in the MasterRPCServices the request running inside a handler will already
contain the required User information from the RPC layer.
> Master region merge RPC should authorize user request
> -----------------------------------------------------
>
> Key: HBASE-15132
> URL: https://issues.apache.org/jira/browse/HBASE-15132
> Project: HBase
> Issue Type: Bug
> Reporter: Ted Yu
> Assignee: Ted Yu
> Attachments: HBASE-15132-branch-1.v6.patch, HBASE-15132.v1.patch,
> HBASE-15132.v2.patch, HBASE-15132.v4.patch, HBASE-15132.v5.patch,
> HBASE-15132.v6.patch, HBASE-15132.v7.patch
>
>
> The normal flow for region merge is:
> 1. client sends a master RPC for dispatch merge regions
> 2. master moves the regions to the same regionserver
> 3. master calls mergeRegions RPC on the regionserver.
> For user initiated region merge, MasterRpcServices#dispatchMergingRegions()
> is called by HBaseAdmin.
> There is no coprocessor invocation in step 1.
> Step 3 is carried out in the "hbase" user context.
> This leaves potential security hole - any user without proper authorization
> can merge regions of any table.
> Thanks to Enis who spotted this flaw first.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
