You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2017/11/21 22:03:00 UTC

[jira] [Created] (HBASE-19318) MasterRpcServices#getSecurityCapabilities explicitly checks for the HBase AccessController implementation

Josh Elser created HBASE-19318:
----------------------------------

             Summary: MasterRpcServices#getSecurityCapabilities explicitly checks for the HBase AccessController implementation
                 Key: HBASE-19318
                 URL: https://issues.apache.org/jira/browse/HBASE-19318
             Project: HBase
          Issue Type: Bug
          Components: master, security
            Reporter: Sharmadha Sainath
            Assignee: Josh Elser
            Priority: Critical
             Fix For: 1.4.0, 1.3.2, 1.2.7, 2.0.0-beta-1


Sharmadha brought a failure to my attention trying to use Ranger with HBase 2.0 where the {{grant}} command was erroring out unexpectedly. The cluster had the Ranger-specific coprocessors deployed, per what was previously working on the HBase 1.1 line.

After some digging, I found that the the Master is actually making a check explicitly for a Coprocessor that has the name {{org.apache.hadoop.hbase.security.access.AccessController}} (short name or full name), instead of looking for a deployed coprocessor which can be assigned to {{AccessController}} (which is what Ranger does). We have the CoprocessorHost methods to do the latter already implemented; it strikes me that we just accidentally used the wrong method in MasterRpcServices.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)