[
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13856548#comment-13856548
]
Andrew Purtell commented on HBASE-6104:
---------------------------------------
I'm not able to reproduce this locally with -Dhadoop.profile=1.1 and Oracle
Java build 1.7.0_21-b11.
I see where in TestAccessController#verifyDenied someone has added code
attempting to deal with UTEs with AccessDeniedException as a nested cause.
Although it would seem the code intends to handle the exception reported by the
failed test here:
{code}
java.lang.reflect.UndeclaredThrowableException: Unknown exception in doAs
Caused by: java.security.PrivilegedActionException:
com.google.protobuf.ServiceException: Error calling method PingService.noop
Caused by: com.google.protobuf.ServiceException: Error calling method
PingService.noop
Caused by:
org.apache.hadoop.hbase.security.AccessDeniedExceptionorg.apache.hadoop.hbase.security.AccessDeniedException:
Insufficient permissions (user=UserB, scope=testCoprocessorExec, family=,
action=EXEC)
Caused by: org.apache.hadoop.hbase.ipc.RemoteWithExtrasException:
org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient
permissions (user=UserB, scope=testCoprocessorExec, family=, action=EXEC)
...
{code}
it didn't work properly.
> 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.98.0, 0.99.0
>
> Attachments: 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)
