[
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859274#comment-13859274
]
Andrew Purtell edited comment on HBASE-6104 at 12/31/13 2:38 AM:
-----------------------------------------------------------------
This is looking better after HBASE-10239. There wasn't an issue with the
feature, it was a unit test problem. Before I commit this to trunk (and maybe
to 0.98... I am tempted ... other security features have been bundled into it),
any comment on the impact to coprocessor users [~lhofhansl] or
[~giacomotaylor]? If the AccessController is active, then you'd have to grant
EXEC to any user (or group of users) who wants to run the Phoenix client before
the coprocessor calls would be allowed. Such grants can be done per user
globally, by namespace, or by table. As Gary mentions in a comment above, we
don't support wildcard grants. However, it is not necessary to grant privileges
per user if all relevant users can belong to a group or groups granted EXEC
privilege.
was (Author: apurtell):
This is looking better after HBASE-10239. There wasn't an issue with the
feature, it was a unit test problem. Before I commit this to trunk (and maybe
to 0.98... I am tempted ... other security features have been bundled into it),
any comment on the impact to coprocessor users [~lhofhansl] or
[~giacomotaylor]? If the AccessController is active, then you'd have to grant
EXEC to any user (or group of users) who wants to run the Phoenix client before
the coprocessor calls would be allowed. Such grants can be done per user
globally, by namespace, or by table. As Gary mentions in a comment above, we
don't support wildcard grants. It's not necessary to grant privileges per user
if all relevant users belong to a group or groups granted EXEC privilege.
> Require EXEC permission to call coprocessor endpoints
> -----------------------------------------------------
>
> Key: HBASE-6104
> URL: https://issues.apache.org/jira/browse/HBASE-6104
> Project: HBase
> Issue Type: New Feature
> Components: Coprocessors, security
> Reporter: Gary Helmling
> Assignee: Andrew Purtell
> Fix For: 0.99.0
>
> Attachments: 6104-addendum-1.patch, 6104-revert.patch, 6104.patch,
> 6104.patch, 6104.patch, 6104.patch, 6104.patch, 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.5#6160)
