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 Thu, 02 Jan 2014 19:13:51 GMT

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

James Taylor commented on HBASE-6104:
-------------------------------------

It's about conserving network bandwidth - we don't want to take the hit of transferring the
same data between client and server multiple times. For example, with secondary indexing,
we'd be tacking on data for every Put - if you have a batch of 10,000, that's a lot of extra
data. We could try to figure out which Put is the "first one" for each region, but what if
a split occurs after we figure this out -- this seems too brittle.
In the case of a Hash Join, we'd be sending over the compressed results of a scan that ran
over the smaller table (which gets joined against in a coprocessor when the scan over the
other table is ran). This can become very large - imagine you're joining against a table with
10M rows. We would not want to send this data for every region of the region server (or even
multiple times per region depending on how the scan gets parallelized on the client).

> 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)

Mime
View raw message