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

Enis Soztutar edited comment on HBASE-14475 at 9/24/15 6:14 PM:
----------------------------------------------------------------

bq. For AccessController to get the user who submitted the request, one 
approach is to add setter to UserProvider for current user. compactSplitThread 
records the current user, calls the setter using passed in User (from 
RSRpcServices) and restores the current user once the split is done.

There is a standard pattern for this already. It is done via {{doAs}}. You can 
check out how procedures do this for example CreateTableProcedure. 
{code}
  private UserGroupInformation user;   // the context user
  ..
  this.user = env.getRequestUser().getUGI();  // the context user is captured 
at the time of request from the handler 

    user.doAs(new PrivilegedExceptionAction<Void>() {
        @Override
        public Void run() throws Exception {
          cpHost.preCreateTableHandler(hTableDescriptor, regions);
          return null;
        }
      });
{code}



was (Author: enis):
bq. For AccessController to get the user who submitted the request, one 
approach is to add setter to UserProvider for current user.
compactSplitThread records the current user, calls the setter using passed in 
User (from RSRpcServices) and restores the current user once the split is done.
There is a standard pattern for this already. It is done via {{doAs}}. You can 
check out how procedures do this for example CreateTableProcedure. 
{code}
  private UserGroupInformation user;   // the context user
  ..
  this.user = env.getRequestUser().getUGI();  // the context user is captured 
at the time of request from the handler 

    user.doAs(new PrivilegedExceptionAction<Void>() {
        @Override
        public Void run() throws Exception {
          cpHost.preCreateTableHandler(hTableDescriptor, regions);
          return null;
        }
      });
{code}


> Region split requests are always audited with "hbase" user rather than 
> request user
> -----------------------------------------------------------------------------------
>
>                 Key: HBASE-14475
>                 URL: https://issues.apache.org/jira/browse/HBASE-14475
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>             Fix For: 2.0.0, 1.3.0
>
>
> [~madhan.neethiraj] from Ranger reported that when a region split request is 
> initiated from the user, we always audit (and do the permission check) 
> against the hbase user, not the request user. 
> The issue is that a split request that is coming from the user is only 
> processed at a later time from the CompactSplitThread asynchronously to the 
> splitRegion RPC.
> RSRpcServices.splitRegion() only does a flush from the handler thread and 
> then calls regionServer.compactSplitThread.requestSplit() which puts a 
> SplitRequest to the split queue. The split request is handled by the split 
> executor from CompactSplitThread.
> Since the split is actually executed from the compact split thread, the 
> preSplit() for the AccessController is called from the executor thread. In 
> this thread, we no longer have the user who initially requested the split, so 
> the user in the context (UGI) is "hbase", causing the AC.preSplit() access 
> control check to be always be performed against the hbase user, not the user 
> who have submitted the request. The audit log also contains "hbase" user 
> rather than the actual user.
> Luckily, the split forces a flush to the region in-line (from the handler 
> thread), which requires a {{CREATE|ADMIN}} permission. split requires 
> {{ADMIN}}, but due to this bug {{CREATE}} is also sufficient (although we 
> have not verified it manually). {{CREATE}} permission can do flush and 
> compactions, so this is not a security issue (I think). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to