[
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854707#comment-13854707
]
Gary Helmling commented on HBASE-6104:
--------------------------------------
I think scoping the EXEC permission to: global, namespace, and table would be a
good start. Scoping to service and method name could be left as a future
addition. For the moment at least, CF doesn't really make sense as endpoint
invocations are only addressed by row key(s).
Backward compatibility is a big concern. Breaking all existing usage would
certainly be bad. But on the other hand a default-allow policy would be at
odds with how all other permissions are handled. This would impact how the
permission grants are stored (would a revoke store a new entry in the "acl"
table instead of removing it?). Or would EXEC be implicitly granted to all
until it is explicitly granted to anyone (also seems confusing)? Just trying
to think through possible approaches.
I guess given the two not-so-great choices, I'm more in favor of the former as
well. While backward compatibility is very important, I think the cost to
consistency in approach is even bigger. Maybe we could go with a big release
note describing the impact along with some migration script to bulk grant EXEC
privs for all configured coprocessors? This might be easier if we had the
capability to create wildcard grants (grant EXEC to "*") as well.
Will look through the patch.
> Require EXEC permission to call coprocessor endpoints
> -----------------------------------------------------
>
> Key: HBASE-6104
> URL: https://issues.apache.org/jira/browse/HBASE-6104
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors, security
> Affects Versions: 0.95.2
> Reporter: Gary Helmling
> Assignee: Andrew Purtell
> Fix For: 0.98.0
>
> Attachments: 6104.patch
>
>
> The EXEC action currently exists as only a placeholder in access control. It
> should really be used to enforce access to coprocessor endpoint RPC calls,
> which are currently unrestricted.
> How the ACLs to support this would be modeled deserves some discussion:
> * Should access be scoped to a specific table and CoprocessorProtocol
> extension?
> * Should it be possible to grant access to a CoprocessorProtocol
> implementation globally (regardless of table)?
> * Are per-method restrictions necessary?
> * Should we expose hooks available to endpoint implementors so that they
> could additionally apply their own permission checks? Some CP endpoints may
> want to require READ permissions, others may want to enforce WRITE, or READ +
> WRITE.
> To apply these kinds of checks we would also have to extend the
> RegionObserver interface to provide hooks wrapping HRegion.exec().
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
