hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Helmling (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
Date Sat, 21 Dec 2013 01:27:07 GMT

    [ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854733#comment-13854733

Gary Helmling commented on HBASE-6104:

Some comments on patch:

# For the new RegionObserver hooks, would it make sense to move these into a new EndpointObserver
coprocessor interface?  They seem logically distinct enough that we could potentially start
breaking things out better.  This would also avoid impact on existing coprocessors (though
that is also minimized by implementing in BaseRegionObserver as you currently do).
# {{RegionObserver.preEndpointInvocation()}} -- I think this should return {{Message}} instead
of a {{void}} return type.  Since PB messages are immutable, this would be needed to allow
mutating the request.
# In AccessController, should there be some special casing for endpoint calls on AccessController
itself?  The AccessControlService methods current check for ADMIN permission on the appropriate
context.  Should the appropriate ADMIN privilege also imply EXEC for those methods?  

> 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

View raw message