hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-14475) Region split requests are always audited with "hbase" user rather than request user
Date Thu, 24 Sep 2015 01:49:04 GMT
Enis Soztutar created HBASE-14475:

             Summary: 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

[~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

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

View raw message