[
https://issues.apache.org/jira/browse/HBASE-19318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265409#comment-16265409
]
Josh Elser commented on HBASE-19318:
------------------------------------
bq. So the intention is to see if the cluster has Accesscontrol services
installed and if so Ranger CP will do necessary actions before the ACL CP is
invoked, right?
Right. This is a smell, but something that Ranger has been doing already (I've
since learned).
bq. Is it right to do this on Ranger side?
No, but I think this is necessary-evil presently.
To Anoop's point, I think it would be better to separate AccessController from
being the coprocessor and the hbase:acl-based authz implementation. With this,
we can:
# Provide a proper interface for folks to implement custom authz logic
# Avoiding unnecessary "system internals" leaking to these impls
I would guess that we could do this in a backwards compat way (new AC
implementation instead of removing the current implementation) and handle it in
2.1.0 rather than waiting for 3.0.
We should involve Ranger folks though ([~vperiasamy]) to make sure that there
isn't more that we're missing which they could benefit from. I would guess that
they had no idea folks in HBase considered authz to be internal-only :)
> 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
>
> Attachments: HBASE-19318.001.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
(v6.4.14#64029)
