You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Gavin (JIRA)" <ji...@apache.org> on 2018/08/01 06:24:26 UTC
[jira] [Issue Comment Deleted] (HBASE-19318)
MasterRpcServices#getSecurityCapabilities explicitly checks for the HBase
AccessController implementation
[ https://issues.apache.org/jira/browse/HBASE-19318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gavin updated HBASE-19318:
--------------------------
Comment: was deleted
(was: A comment with security level 'jira-users' was removed.)
> 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: 2.0.0-beta-1, 2.0.0
>
> Attachments: HBASE-19318.001.branch-2.patch, HBASE-19318.002.branch-2.patch
>
>
> 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
(v7.6.3#76005)