[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13863663#comment-13863663
]
Hadoop QA commented on HBASE-6104:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12621697/6104.patch
against trunk revision .
ATTACHMENT ID: 12621697
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 8 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 4 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8350//console
This message is automatically generated.
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-addendum-1.patch, 6104-revert.patch, 6104.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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13863888#comment-13863888 ] Hudson commented on HBASE-6104: --- SUCCESS: Integrated in HBase-0.98 #62 (See [https://builds.apache.org/job/HBase-0.98/62/]) HBASE-6104. Require EXEC permission to call coprocessor endpoints (apurtell: rev 1556100) * /hbase/branches/0.98/hbase-common/src/main/resources/hbase-default.xml * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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-addendum-1.patch, 6104-revert.patch, 6104.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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13863895#comment-13863895 ] Hudson commented on HBASE-6104: --- SUCCESS: Integrated in HBase-TRUNK #4796 (See [https://builds.apache.org/job/HBase-TRUNK/4796/]) HBASE-6104. Require EXEC permission to call coprocessor endpoints (apurtell: rev 1556098) * /hbase/trunk/hbase-common/src/main/resources/hbase-default.xml * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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-addendum-1.patch, 6104-revert.patch, 6104.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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13863918#comment-13863918 ] Hudson commented on HBASE-6104: --- SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #56 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/56/]) HBASE-6104. Require EXEC permission to call coprocessor endpoints (apurtell: rev 1556100) * /hbase/branches/0.98/hbase-common/src/main/resources/hbase-default.xml * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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-addendum-1.patch, 6104-revert.patch, 6104.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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13863933#comment-13863933 ] Hudson commented on HBASE-6104: --- SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-1.1 #45 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/45/]) HBASE-6104. Require EXEC permission to call coprocessor endpoints (apurtell: rev 1556098) * /hbase/trunk/hbase-common/src/main/resources/hbase-default.xml * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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-addendum-1.patch, 6104-revert.patch, 6104.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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13860505#comment-13860505 ] Andrew Purtell commented on HBASE-6104: --- Thanks for the feedback [~giacomotaylor]. Yes, EXEC privilege affects only the invocation of endpoints. The essential change is if a user is not granted EXEC permission then the invocation will be rejected. Regarding your point #2, what prevents your observer from taking the data in an attribute of the first mutation presented and applying it on a regionserver level? Whether your observer does something locally on the region or globally on the regionserver in response to an attribute is up to you. LarsH put in state sharing for region observers in HBASE-6505. 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13860513#comment-13860513 ] Andrew Purtell commented on HBASE-6104: --- Will wait on commit to trunk for a bit pending additional discussion. 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13860652#comment-13860652 ] Andrew Purtell commented on HBASE-6104: --- This discussion is about HBASE-9291. Let's take it there. Regarding requiring an EXEC privilege to call coprocessor endpoints, the feedback is that security would be inconvenient. Unfortunately, that's the nature of security. Will commit this to trunk shortly. 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13860683#comment-13860683 ] Andrew Purtell commented on HBASE-6104: --- If we introduce a new client API to the effect of send one RPC to each RS, then this amounts to a modified coprocessor endpoint execution, but with an invocation target that is a singleton to each RS, and should be subject to the same security considerations. Passing an attribute on the first put to a RS sidesteps the need for EXEC grants on any endpoint invocation target. Remainder of response on HBASE-9291. 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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, [~andrew.purt...@gmail.com]? 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859274#comment-13859274 ] Andrew Purtell commented on HBASE-6104: --- 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13857416#comment-13857416 ] Hudson commented on HBASE-6104: --- FAILURE: Integrated in HBase-0.98 #39 (See [https://builds.apache.org/job/HBase-0.98/39/]) Revert HBASE-6104. Revert initial commit and addendum (apurtell: rev 1553451) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13857648#comment-13857648 ] Andrew Purtell commented on HBASE-6104: --- If TestAccessController is green after HBASE-10239 for a few trunk builds, my plan is to try committing this change again, but only to trunk. 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856850#comment-13856850 ] Hudson commented on HBASE-6104: --- FAILURE: Integrated in HBase-TRUNK #4761 (See [https://builds.apache.org/job/HBase-TRUNK/4761/]) Revert HBASE-6104. Revert initial commit and addendum (apurtell: rev 1553450) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java Amend HBASE-6104. TestAccessController#testCoprocessorExec is improperly failing (apurtell: rev 1553446) * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java 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 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856945#comment-13856945 ] Andrew Purtell commented on HBASE-6104: --- TestAccessController improvements filed as HBASE-10239 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 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856545#comment-13856545 ] Andrew Purtell commented on HBASE-6104: --- Looks like the new unit test needs an update to pass on Hadoop 1: https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/33/testReport/junit/org.apache.hadoop.hbase.security.access/TestAccessController/testCoprocessorExec/ 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856620#comment-13856620 ] Hudson commented on HBASE-6104: --- FAILURE: Integrated in HBase-TRUNK #4757 (See [https://builds.apache.org/job/HBase-TRUNK/4757/]) HBASE-6104. Require EXEC permission to call coprocessor endpoints. Add missing file (apurtell: rev 1553347) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java HBASE-6104. Require EXEC permission to call coprocessor endpoints (apurtell: rev 1553344) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856690#comment-13856690 ] Hudson commented on HBASE-6104: --- FAILURE: Integrated in HBase-TRUNK-on-Hadoop-1.1 #23 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/23/]) HBASE-6104. Require EXEC permission to call coprocessor endpoints. Add missing file (apurtell: rev 1553347) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java HBASE-6104. Require EXEC permission to call coprocessor endpoints (apurtell: rev 1553344) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856746#comment-13856746 ] Andrew Purtell commented on HBASE-6104: --- Unscheduling from 0.98. 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 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856781#comment-13856781 ] Hudson commented on HBASE-6104: --- SUCCESS: Integrated in HBase-0.98 #37 (See [https://builds.apache.org/job/HBase-0.98/37/]) Amend HBASE-6104. TestAccessController#testCoprocessorExec is improperly failing (apurtell: rev 1553447) * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java 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 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856787#comment-13856787 ] Hudson commented on HBASE-6104: --- SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #36 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/36/]) Revert HBASE-6104. Revert initial commit and addendum (apurtell: rev 1553451) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java Amend HBASE-6104. TestAccessController#testCoprocessorExec is improperly failing (apurtell: rev 1553447) * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java 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 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856790#comment-13856790 ] Hudson commented on HBASE-6104: --- SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-1.1 #25 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/25/]) Revert HBASE-6104. Revert initial commit and addendum (apurtell: rev 1553450) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java Amend HBASE-6104. TestAccessController#testCoprocessorExec is improperly failing (apurtell: rev 1553446) * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java 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 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856452#comment-13856452 ] Andrew Purtell commented on HBASE-6104: --- HBASE-10226 went in, will commit this later today. 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 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856539#comment-13856539 ] Hudson commented on HBASE-6104: --- SUCCESS: Integrated in HBase-0.98 #34 (See [https://builds.apache.org/job/HBase-0.98/34/]) HBASE-6104. Require EXEC permission to call coprocessor endpoints (apurtell: rev 1553345) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13856541#comment-13856541 ] Hudson commented on HBASE-6104: --- FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #33 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/33/]) HBASE-6104. Require EXEC permission to call coprocessor endpoints (apurtell: rev 1553345) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/EndpointObserver.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithACL.java 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855354#comment-13855354
]
Hadoop QA commented on HBASE-6104:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12620110/6104.patch
against trunk revision .
ATTACHMENT ID: 12620110
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithACL
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8260//console
This message is automatically generated.
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
Reporter: Gary Helmling
Assignee: Andrew Purtell
Fix For: 0.98.0, 0.99.0
Attachments: 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855356#comment-13855356 ] Andrew Purtell commented on HBASE-6104: --- The TestVisibilityLabelsWithACL.testLabelsTableOpsWithDifferentUsers failure is a real issue with the test. 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 Reporter: Gary Helmling Assignee: Andrew Purtell Fix For: 0.98.0, 0.99.0 Attachments: 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855398#comment-13855398
]
Hadoop QA commented on HBASE-6104:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12620120/6104.patch
against trunk revision .
ATTACHMENT ID: 12620120
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8261//console
This message is automatically generated.
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
Reporter: Gary Helmling
Assignee: Andrew Purtell
Fix For: 0.98.0, 0.99.0
Attachments: 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855450#comment-13855450 ] Andrew Purtell commented on HBASE-6104: --- Significant functional change - can I get another review / +1: [~stack], [~anoop.hbase], [~ram_krish] ? 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 Reporter: Gary Helmling Assignee: Andrew Purtell Fix For: 0.98.0, 0.99.0 Attachments: 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855461#comment-13855461 ] Anoop Sam John commented on HBASE-6104: --- +1 So this breaks the compatability for endpoints when Security is in place. Right Andy? We can highlight this. (You will make some changes in book?) 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 Reporter: Gary Helmling Assignee: Andrew Purtell Fix For: 0.98.0, 0.99.0 Attachments: 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855469#comment-13855469 ] Andrew Purtell commented on HBASE-6104: --- bq. So this breaks the compatibility for endpoints when Security is in place. See the release note on this issue. Is it sufficient? We are not changing APIs, but yes if the AccessController is active than, for example, granting a user the ability to do a secure bulk load will require granting EXEC privilege as well as the others, because that is a coprocessor endpoint based service. Now that I'm thinking about it, let me add a unit test that insures EXEC if granted to an entire namespace works as expected. 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 Reporter: Gary Helmling Assignee: Andrew Purtell Fix For: 0.98.0, 0.99.0 Attachments: 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13855479#comment-13855479 ] ramkrishna.s.vasudevan commented on HBASE-6104: --- +1 on patch. Looks good to me. The release note also is good . 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 Reporter: Gary Helmling Assignee: Andrew Purtell Fix For: 0.98.0, 0.99.0 Attachments: 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)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854614#comment-13854614 ] Andrew Purtell commented on HBASE-6104: --- We could either put up a fat release note that says to the effect now you MUST immediately grant all relevant users the ability to execute coprocessors on the respective tables, or grandfather EXEC privilege to all users by default. Thoughts? I think the former makes more sense, but the latter would be transparently backwards compatible. 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 (v6.1.4#6159)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854707#comment-13854707 ] Gary Helmling commented on HBASE-6104: -- I think scoping the EXEC permission to: global, namespace, and table would be a good start. Scoping to service and method name could be left as a future addition. For the moment at least, CF doesn't really make sense as endpoint invocations are only addressed by row key(s). Backward compatibility is a big concern. Breaking all existing usage would certainly be bad. But on the other hand a default-allow policy would be at odds with how all other permissions are handled. This would impact how the permission grants are stored (would a revoke store a new entry in the acl table instead of removing it?). Or would EXEC be implicitly granted to all until it is explicitly granted to anyone (also seems confusing)? Just trying to think through possible approaches. I guess given the two not-so-great choices, I'm more in favor of the former as well. While backward compatibility is very important, I think the cost to consistency in approach is even bigger. Maybe we could go with a big release note describing the impact along with some migration script to bulk grant EXEC privs for all configured coprocessors? This might be easier if we had the capability to create wildcard grants (grant EXEC to *) as well. Will look through the patch. 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 (v6.1.4#6159)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854709#comment-13854709 ] Andrew Purtell commented on HBASE-6104: --- bq. This might be easier if we had the capability to create wildcard grants (grant EXEC to *) as well. We can do that in effect by granting a user GLOBAL 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: 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 (v6.1.4#6159)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854714#comment-13854714 ] Gary Helmling commented on HBASE-6104: -- Sorry my example wasn't very clear. I meant the * to represent the username, so effectively doing a default allow to all users. Don't think we support this yet? Certain combinations would still be problematic -- if I grant to * users, then try to revoke for a single user is that allowed or does it error out? 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 (v6.1.4#6159)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854715#comment-13854715 ] Andrew Purtell commented on HBASE-6104: --- Yeah we don't support that. 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 (v6.1.4#6159)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
(v6.1.4#6159)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854752#comment-13854752 ] Gary Helmling commented on HBASE-6104: -- Latest patch looks good to me. +1 if it fixes the test failure. Any chance of an extra test for the EXEC permissions handling? Could be added to TestAccessController or TestServerCustomProtocol. 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, 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.4#6159)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13854753#comment-13854753 ] Andrew Purtell commented on HBASE-6104: --- Thanks for the +1 Gary. I will have to fix the test failure and add a unit test for EXEC checking to TestAccessController. Will put up a final patch to sit here a bit before commit. Thanks again for looking at this. 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, 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.4#6159)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833254#comment-13833254 ] Andrew Purtell commented on HBASE-6104: --- Will try to look at this for 0.98, no promises, thinking of branching on 12/1 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 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#6144)
[jira] [Commented] (HBASE-6104) Require EXEC permission to call coprocessor endpoints
[ https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13283720#comment-13283720 ] Andrew Purtell commented on HBASE-6104: --- bq. To apply these kinds of checks we would also have to extend the RegionObserver interface to provide hooks wrapping HRegion.exec(). +1 on this at a minimum. bq. Should access be scoped to a specific table and CoprocessorProtocol extension? bq. Should it be possible to grant access to a CoprocessorProtocol implementation globally (regardless of table)? bq. Are per-method restrictions necessary? For the sake of simplicity, I suggest considering an EXEC permission per CF. So that would allow the user or group specified in the grant to execute any coprocessors installed in the region for the given CF. We can do more, but it would be good to be informed by a specific use case then. 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 Reporter: Gary Helmling 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
