[jira] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2014-01-06 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Fix Version/s: 0.98.0

bq. Before I commit this to trunk (and maybe to 0.98... I am tempted ... other 
security features have been bundled into it)

I am going to bring this into 0.98, but one more rev of the patch first: Let's 
make enforcement of EXEC privilege optional and disabled by default for 0.98, 
then on unconditionally in a later release.

 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


 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2014-01-06 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104.patch

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2014-01-06 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Status: Patch Available  (was: Reopened)

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2014-01-06 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Release Note: If access control is active (the AccessController coprocessor 
is installed either as a system coprocessor or on a table as a table 
coprocessor) and the hbase.security.exec.permission.checks configuration 
setting is true, then you must now grant all relevant users EXEC privilege if 
they require the ability to execute coprocessor endpoint calls. EXEC privilege, 
like any other permission, can be granted globally to a user, or to a user on a 
per table or per namespace basis. For more information on coprocessor 
endpoints, see the coprocessor section of the HBase online manual. For more 
information on granting or revoking permissions using the AccessController, see 
the security section of the HBase online manual.  (was: If access control is 
active (the AccessController coprocessor is installed either as a system 
coprocessor or on a table as a table coprocessor) then you must now grant all 
relevant users EXEC privilege if they require the ability to execute 
coprocessor endpoint calls. EXEC privilege, like any other permission, can be 
granted globally to a user, or to a user on a per table or per namespace basis. 
For more information on coprocessor endpoints, see the coprocessor section of 
the HBase online manual. For more information on granting or revoking 
permissions using the AccessController, see the security section of the HBase 
online manual.)

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2014-01-06 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Committed to trunk and 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.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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-26 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104.patch

Back for more.

Attaching new patch that won't apply until after HBASE-10239 goes in. New test 
case for EXEC permission passes several times locally on JDK6 and 7, including 
the specific JDK (Oracle 6u43) I managed to reproduce the Jenkins failure with.

Could be (re)considered for commit 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-25 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104-addendum-1.patch

 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.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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-25 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104-revert.patch

 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


 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-25 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Fix Version/s: (was: 0.98.0)

Attached the patch I used to revert this. Needs more work and a test that 
passes reliably on various JDK 6 and JDK 7 versions.

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-24 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Issue Type: New Feature  (was: Sub-task)
Parent: (was: HBASE-9945)

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-23 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104.patch

Latest patch contains new unit test that won't pass until HBASE-10226 is 
committed first.

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-23 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Release Note: If access control is active (the AccessController coprocessor 
is installed either as a system coprocessor or on a table as a table 
coprocessor) then you must now grant all relevant users EXEC privilege if they 
require the ability to execute coprocessor endpoint calls. EXEC privilege, like 
any other permission, can be granted globally to a user, or to a user on a per 
table or per namespace basis. For more information on coprocessor endpoints, 
see the coprocessor section of the HBase online manual. For more information on 
granting or revoking permissions using the AccessController, see the security 
section of the HBase online manual.  (was: If access control is active (the 
AccessController coprocessor is installed either as a system coprocessor or on 
a table as a table coprocessor) then you must now grant all relevant users EXEC 
privilege if they require the ability to execute coprocessor endpoint calls. 
EXEC privilege, like any other permission, can be granted globally to a user, 
or on a per table basis. For more information on coprocessor endpoints, see the 
coprocessor section of the HBase online manual. For more information on 
granting or revoking permissions using the AccessController, see the security 
section of the HBase online manual.)

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-22 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104.patch

Latest patch includes new unit test in TestAccessController for checking 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, 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-22 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Fix Version/s: 0.99.0
Affects Version/s: (was: 0.95.2)
   Status: Patch Available  (was: Open)

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-22 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Release Note: If access control is active (the AccessController coprocessor 
is installed either as a system coprocessor or on a table as a table 
coprocessor) then you must now grant all relevant users EXEC privilege if they 
require the ability to execute coprocessor endpoint calls. EXEC privilege, like 
any other permission, can be granted globally to a user, or on a per table 
basis. For more information on coprocessor endpoints, see the coprocessor 
section of the HBase online manual. For more information on granting or 
revoking permissions using the AccessController, see the security section of 
the HBase online manual.

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-22 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Status: Open  (was: Patch Available)

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-22 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Status: Patch Available  (was: Open)

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-22 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104.patch

New patch including test fix.

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-22 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Status: Open  (was: Patch Available)

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-20 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104.patch

bq. For the sake of simplicity, I suggest considering an EXEC permission per CF.

Simplifying this even further, why not just a test for if the user has EXEC 
permission on the table. Attached is a patch to trunk which does that. Now, the 
question is how many unit tests does this break. Working on that now.

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-20 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104.patch

Something like this?

With the previous patch only TestVisibilityLabelsWithACL failed, looking into 
it.

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-20 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: 6104.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, 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-12-20 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Attachment: (was: 6104.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, 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-11-11 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Parent Issue: HBASE-9945  (was: HBASE-6096)

 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

 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2013-11-11 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Fix Version/s: 0.98.0

 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
 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] [Updated] (HBASE-6104) Require EXEC permission to call coprocessor endpoints

2012-05-25 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-6104:
--

Affects Version/s: 0.96.0

 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.96.0
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