hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
Date Wed, 01 Jan 2014 01:17:50 GMT

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

James Taylor commented on HBASE-6104:

Does this effect only end point coprocessors? If so, we have two end point coprocessors:
1) For issuing DDL statements. Probably not a bad idea to have to require an extra grant for
a user to do this. The only exception might be still allowing users to create a tenant-specific
table for a multi-tenant base table.
2) For sending region server level cache information, as there's no good way to do this from
a region observer coprocessor (see https://issues.apache.org/jira/browse/HBASE-9291). This
is used for both joins (for broadcasting the hash join cache to each region server) plus for
secondary indexing (to pass along the index metadata for index row building, so we don't have
to attach this information to every single Put/Delete). Requiring additional security to be
able to do joins and/or use secondary indexing is not good. How about a fix for HBASE-9291
so that we could tack along attributes to go with the mutation on a per region server basis,

> 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

View raw message