from:"Laxman \(JIRA\)"

[jira] [Updated] (HBASE-5650) [findbugs] Address extra synchronization on CLSM, Atomic*

2014-12-22 Thread Laxman (JIRA)


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

Laxman updated HBASE-5650:
--
Assignee: (was: Laxman)

 [findbugs] Address extra synchronization on CLSM, Atomic*
 -

 Key: HBASE-5650
 URL: https://issues.apache.org/jira/browse/HBASE-5650
 Project: HBase
  Issue Type: Sub-task
  Components: scripts
Reporter: Jonathan Hsieh

 See 
 https://builds.apache.org/job/PreCommit-HBASE-Build/1313//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html#Warnings_MT_CORRECTNESS
 Fix/exclude class JLM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-5649) [findbugs] Fix security warning

2014-12-22 Thread Laxman (JIRA)


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

Laxman updated HBASE-5649:
--
Assignee: (was: Laxman)

 [findbugs] Fix security warning
 ---

 Key: HBASE-5649
 URL: https://issues.apache.org/jira/browse/HBASE-5649
 Project: HBase
  Issue Type: Sub-task
  Components: scripts
Reporter: Jonathan Hsieh

 See 
 https://builds.apache.org/job/PreCommit-HBASE-Build/1313//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html#Warnings_SECURITY
 Fix possible XSS Vuln.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-6418) Minor bug in delete flow.

2012-07-24 Thread Laxman (JIRA)


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

Laxman resolved HBASE-6418.
---

Resolution: Not A Problem

 Minor bug in delete flow.
 -

 Key: HBASE-6418
 URL: https://issues.apache.org/jira/browse/HBASE-6418
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0, 0.96.0, 0.94.1, 0.94.2
Reporter: Laxman
Assignee: Laxman

 Timestamp updation in Delete flow is not considering all flavors (Delete 
 record, Delete Family, Delete Column) of Delete API. Currently its 
 considering Delete Record only. 
  
 org.apache.hadoop.hbase.regionserver.HRegion.prepareDeleteTimestamps(Delete, 
 byte[])
 {code}
   for (KeyValue kv: kvs) {
 //  Check if time is LATEST, change to time of most recent addition 
 if so
 //  This is expensive.
 if (kv.isLatestTimestamp()  kv.isDeleteType()) {
 {code}
 Basically used a wrong API.
 kv.isDeleteType() should be KeyValue.isDelete(type);

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

[jira] [Commented] (HBASE-6418) Minor bug in delete flow.

2012-07-18 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418089#comment-13418089
 ] 

Laxman commented on HBASE-6418:
---

@Lars  Anoop, thanks for clarifying.

Honestly I didn't go through the existing doc as well. While walking thru the 
code flow, it looked a bit strange.

Apologies for the noise.

 Minor bug in delete flow.
 -

 Key: HBASE-6418
 URL: https://issues.apache.org/jira/browse/HBASE-6418
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0, 0.96.0, 0.94.1, 0.94.2
Reporter: Laxman
Assignee: Laxman

 Timestamp updation in Delete flow is not considering all flavors (Delete 
 record, Delete Family, Delete Column) of Delete API. Currently its 
 considering Delete Record only. 
  
 org.apache.hadoop.hbase.regionserver.HRegion.prepareDeleteTimestamps(Delete, 
 byte[])
 {code}
   for (KeyValue kv: kvs) {
 //  Check if time is LATEST, change to time of most recent addition 
 if so
 //  This is expensive.
 if (kv.isLatestTimestamp()  kv.isDeleteType()) {
 {code}
 Basically used a wrong API.
 kv.isDeleteType() should be KeyValue.isDelete(type);

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

[jira] [Created] (HBASE-6418) Minor bug in delete flow.

2012-07-17 Thread Laxman (JIRA)

Laxman created HBASE-6418:
-

 Summary: Minor bug in delete flow.
 Key: HBASE-6418
 URL: https://issues.apache.org/jira/browse/HBASE-6418
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0, 0.96.0, 0.94.1, 0.94.2
Reporter: Laxman
Assignee: Laxman


Timestamp updation in Delete flow is not considering all flavors (Delete 
record, Delete Family, Delete Column) of Delete API. Currently its considering 
Delete Record only. 
 
org.apache.hadoop.hbase.regionserver.HRegion.prepareDeleteTimestamps(Delete, 
byte[])

{code}
  for (KeyValue kv: kvs) {
//  Check if time is LATEST, change to time of most recent addition if 
so
//  This is expensive.
if (kv.isLatestTimestamp()  kv.isDeleteType()) {
{code}

Basically used a wrong API.
kv.isDeleteType() should be KeyValue.isDelete(type);


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

[jira] [Commented] (HBASE-5498) Secure Bulk Load

2012-07-16 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13415903#comment-13415903
]

Laxman commented on HBASE-5498:
---

That's fine Francis.
I'm also trying out on HBase 0.94.x + Hadoop 2.0.x.

When you give a try, ensure the bulkload is done from a non-super user (not
HBase and not HDFS).

Secure Bulk Load

Key: HBASE-5498
URL: https://issues.apache.org/jira/browse/HBASE-5498
Project: HBase
Issue Type: Improvement
Components: mapred, security
Reporter: Francis Liu
Assignee: Francis Liu
Fix For: 0.96.0

Attachments: HBASE-5498_draft.patch

Design doc:
https://cwiki.apache.org/confluence/display/HCATALOG/HBase+Secure+Bulk+Load
Short summary:
Security as it stands does not cover the bulkLoadHFiles() feature. Users
calling this method will bypass ACLs. Also loading is made more cumbersome in
a secure setting because of hdfs privileges. bulkLoadHFiles() moves the data
from user's directory to the hbase directory, which would require certain
write access privileges set.
Our solution is to create a coprocessor which makes use of AuthManager to
verify if a user has write access to the table. If so, launches a MR job as
the hbase user to do the importing (ie rewrite from text to hfiles). One
tricky part this job will have to do is impersonate the calling user when
reading the input files. We can do this by expecting the user to pass an hdfs
delegation token as part of the secureBulkLoad() coprocessor call and extend
an inputformat to make use of that token. The output is written to a
temporary directory accessible only by hbase and then bulkloadHFiles() is
called.

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

[jira] [Commented] (HBASE-5498) Secure Bulk Load

2012-07-12 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13412719#comment-13412719
 ] 

Laxman commented on HBASE-5498:
---

Thanks for correction Francis.

I tried as per your suggestion. Still no luck. Now we are hitting the same 
Permission denied problem. On further investigation, I found that the DFS 
requests(rename) is still going with hbase user. FS is initialized as hbase 
user during coprocessor initialization on startup. I moved FS initialization 
like below. 

{code}
boolean success = ugi.doAs(new PrivilegedActionBoolean() {
  @Override
  public Boolean run() {
FileSystem fs=null;
try {
  fs=FileSystem.get(conf);
  setPermission(fs, srcPath, new FsPermission((short) 0777));
  fs.rename(srcPath, contentPath);
  LOG.info(moving  + srcPath +  to  + contentPath);
  completeBulkLoad(tableName, contentPath);
  ...
{code}

With this, I'm hitting a brand new problem.
{noformat}
2012-07-12 16:23:43,839 ERROR 
org.apache.hadoop.hbase.security.access.SecureBulkLoadEndPoint: Failed to 
complete bulk load
java.lang.NullPointerException
at javax.security.auth.Subject$ClassSet.populateSet(Subject.java:1351)
at javax.security.auth.Subject$ClassSet.init(Subject.java:1317)
at javax.security.auth.Subject.getPrivateCredentials(Subject.java:731)
at 
org.apache.hadoop.security.UserGroupInformation.init(UserGroupInformation.java:488)
at 
org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:514)
at org.apache.hadoop.hdfs.DFSClient.init(DFSClient.java:346)
at org.apache.hadoop.hdfs.DFSClient.init(DFSClient.java:327)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:121)
{noformat}

Based on this stacktrace analysis, this occurred as we continue without logging 
in ugi.login().
But this ugi.login supports keytab/ticket cache which I don't have for test 
on region-server side.

I think I'm missing some fundamental point in token delegation.

Apologies for too much of text.

 Secure Bulk Load
 

 Key: HBASE-5498
 URL: https://issues.apache.org/jira/browse/HBASE-5498
 Project: HBase
  Issue Type: Improvement
  Components: mapred, security
Reporter: Francis Liu
Assignee: Francis Liu
 Fix For: 0.96.0

 Attachments: HBASE-5498_draft.patch


 Design doc: 
 https://cwiki.apache.org/confluence/display/HCATALOG/HBase+Secure+Bulk+Load
 Short summary:
 Security as it stands does not cover the bulkLoadHFiles() feature. Users 
 calling this method will bypass ACLs. Also loading is made more cumbersome in 
 a secure setting because of hdfs privileges. bulkLoadHFiles() moves the data 
 from user's directory to the hbase directory, which would require certain 
 write access privileges set.
 Our solution is to create a coprocessor which makes use of AuthManager to 
 verify if a user has write access to the table. If so, launches a MR job as 
 the hbase user to do the importing (ie rewrite from text to hfiles). One 
 tricky part this job will have to do is impersonate the calling user when 
 reading the input files. We can do this by expecting the user to pass an hdfs 
 delegation token as part of the secureBulkLoad() coprocessor call and extend 
 an inputformat to make use of that token. The output is written to a 
 temporary directory accessible only by hbase and then bulkloadHFiles() is 
 called.

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

[jira] [Commented] (HBASE-5498) Secure Bulk Load

2012-07-11 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411543#comment-13411543
 ] 

Laxman commented on HBASE-5498:
---

I tried this draft patch. 

*Scenario*
1) As hbase: Create a table employee. Grant permissions to test user.
2) As hdfs: Create dir /test and make test as owner.
3) As test: Place the tsv input in /test/input and run importtsv from 
command line as earlier.
4) As test: Run the following snippet to do completebulkload. I'm not sure 
whether this is correct usage.
{code}
HTable table = new HTable(HBaseConfiguration.create(), employee);
AuthenticationProtocol auth = 
table.coprocessorProxy(AuthenticationProtocol.class,
HConstants.EMPTY_START_ROW);
TokenAuthenticationTokenIdentifier token = auth.getAuthenticationToken();
SecureBulkLoadProtocol proxy = 
table.coprocessorProxy(SecureBulkLoadProtocol.class,
HConstants.EMPTY_START_ROW);
proxy.secureCompleteBulkLoad(employee, 
hdfs://10.18.40.92:9000/test/bulkload/output, token);
{code}

First phase (i.e. importtsv) worked fine.
For the second phase (i.e. completebulkload) I used the following snippet as my 
client code.

But I'm hitting the following exception on region server side.
{noformat}
2012-07-11 19:23:38,529 ERROR 
org.apache.hadoop.hbase.security.access.SecureBulkLoadEndPoint: Failed to 
secure bulk load
org.apache.hadoop.security.AccessControlException: Permission denied
at 
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkOwner(FSPermissionChecker.java:155)
at 
org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:147)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkPermission(FSNamesystem.java:4271)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.checkOwner(FSNamesystem.java:4227)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.setPermission(FSNamesystem.java:1010)
{noformat}

 Secure Bulk Load
 

 Key: HBASE-5498
 URL: https://issues.apache.org/jira/browse/HBASE-5498
 Project: HBase
  Issue Type: Improvement
  Components: mapred, security
Reporter: Francis Liu
Assignee: Francis Liu
 Fix For: 0.96.0

 Attachments: HBASE-5498_draft.patch


 Design doc: 
 https://cwiki.apache.org/confluence/display/HCATALOG/HBase+Secure+Bulk+Load
 Short summary:
 Security as it stands does not cover the bulkLoadHFiles() feature. Users 
 calling this method will bypass ACLs. Also loading is made more cumbersome in 
 a secure setting because of hdfs privileges. bulkLoadHFiles() moves the data 
 from user's directory to the hbase directory, which would require certain 
 write access privileges set.
 Our solution is to create a coprocessor which makes use of AuthManager to 
 verify if a user has write access to the table. If so, launches a MR job as 
 the hbase user to do the importing (ie rewrite from text to hfiles). One 
 tricky part this job will have to do is impersonate the calling user when 
 reading the input files. We can do this by expecting the user to pass an hdfs 
 delegation token as part of the secureBulkLoad() coprocessor call and extend 
 an inputformat to make use of that token. The output is written to a 
 temporary directory accessible only by hbase and then bulkloadHFiles() is 
 called.

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

[jira] [Commented] (HBASE-5498) Secure Bulk Load

2012-07-10 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13410151#comment-13410151
]

Laxman commented on HBASE-5498:
---

@Francis, do you have updated patch for Task #1.

Secure Bulk Load

Key: HBASE-5498
URL: https://issues.apache.org/jira/browse/HBASE-5498
Project: HBase
Issue Type: Improvement
Components: mapred, security
Reporter: Francis Liu
Assignee: Francis Liu
Fix For: 0.96.0

Attachments: HBASE-5498_draft.patch

[jira] [Commented] (HBASE-5498) Secure Bulk Load

2012-07-10 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13410152#comment-13410152
]

Laxman commented on HBASE-5498:
---

bq. @Francis, do you have updated patch for Task #1.

Sorry. Task #2 actually. HBASE-6225

Secure Bulk Load

Key: HBASE-5498
URL: https://issues.apache.org/jira/browse/HBASE-5498
Project: HBase
Issue Type: Improvement
Components: mapred, security
Reporter: Francis Liu
Assignee: Francis Liu
Fix For: 0.96.0

Attachments: HBASE-5498_draft.patch

[jira] [Commented] (HBASE-5498) Secure Bulk Load

2012-07-10 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411237#comment-13411237
]

Laxman commented on HBASE-5498:
---

That's fine Francis. Currently I'm trying out your initial patch.
Will post my findings soon.

BTW, can you please tell me how to invoke this secure bulkload (complete
bulkload step)?
Should this be a plugged into Driver like earlier bulkload?

Secure Bulk Load

Key: HBASE-5498
URL: https://issues.apache.org/jira/browse/HBASE-5498
Project: HBase
Issue Type: Improvement
Components: mapred, security
Reporter: Francis Liu
Assignee: Francis Liu
Fix For: 0.96.0

Attachments: HBASE-5498_draft.patch

[jira] [Commented] (HBASE-6292) Compact can skip the security access control

2012-07-01 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404702#comment-13404702
 ] 

Laxman commented on HBASE-6292:
---

bq. Should we change the doc for the ACL Matrix?

Yes ShiXing.

bq. I will update the matrix HBASE-6192 accordingly.

 Compact can skip the security access control
 

 Key: HBASE-6292
 URL: https://issues.apache.org/jira/browse/HBASE-6292
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: ShiXing
Assignee: ShiXing
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6292-trunk-V1.patch


 When client sends compact command to rs, the rs just create a 
 CompactionRequest, and then put it into the thread pool to process the 
 CompactionRequest. And when the region do the compact, it uses the rs's ugi 
 to process the compact, so the compact can successfully done.
 Example:
 user mapred do not have permission Admin,
 {code}
 hbase(main):001:0 user_permission 'Security'
 UserTable,Family,Qualifier:Permission 
  
  mapred Security,f1,c1: [Permission: 
 actions=READ,WRITE] 
 hbase(main):004:0 put 'Security', 'r6', 'f1:c1', 'v9'
 0 row(s) in 0.0590 seconds
 hbase(main):005:0 put 'Security', 'r6', 'f1:c1', 'v10'
 0 row(s) in 0.0040 seconds
 hbase(main):006:0 compact 'Security'
 0 row(s) in 0.0260 seconds
 {code}
 Maybe we can add permission check in the preCompactSelection() ?

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

[jira] [Commented] (HBASE-6292) Compact can skip the security access control

2012-06-29 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403862#comment-13403862
 ] 

Laxman commented on HBASE-6292:
---

yes shixing, seems to be a problem. do you have a patch for this?

I will update the matrix [HBASE-6192] accordingly.


 Compact can skip the security access control
 

 Key: HBASE-6292
 URL: https://issues.apache.org/jira/browse/HBASE-6292
 Project: HBase
  Issue Type: Bug
  Components: security
Reporter: ShiXing
Assignee: ShiXing

 When client sends compact command to rs, the rs just create a 
 CompactionRequest, and then put it into the thread pool to process the 
 CompactionRequest. And when the region do the compact, it uses the rs's ugi 
 to process the compact, so the compact can successfully done.
 Example:
 user mapred do not have permission Admin,
 {code}
 hbase(main):001:0 user_permission 'Security'
 UserTable,Family,Qualifier:Permission 
  
  mapred Security,f1,c1: [Permission: 
 actions=READ,WRITE] 
 hbase(main):004:0 put 'Security', 'r6', 'f1:c1', 'v9'
 0 row(s) in 0.0590 seconds
 hbase(main):005:0 put 'Security', 'r6', 'f1:c1', 'v10'
 0 row(s) in 0.0040 seconds
 hbase(main):006:0 compact 'Security'
 0 row(s) in 0.0260 seconds
 {code}
 Maybe we can add permission check in the preCompactSelection() ?

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

[jira] [Updated] (HBASE-6292) Compact can skip the security access control

2012-06-29 Thread Laxman (JIRA)


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

Laxman updated HBASE-6292:
--

Affects Version/s: 0.94.1
   0.96.0
   0.94.0
   Labels: acl security  (was: )

 Compact can skip the security access control
 

 Key: HBASE-6292
 URL: https://issues.apache.org/jira/browse/HBASE-6292
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: ShiXing
Assignee: ShiXing
  Labels: acl, security

 When client sends compact command to rs, the rs just create a 
 CompactionRequest, and then put it into the thread pool to process the 
 CompactionRequest. And when the region do the compact, it uses the rs's ugi 
 to process the compact, so the compact can successfully done.
 Example:
 user mapred do not have permission Admin,
 {code}
 hbase(main):001:0 user_permission 'Security'
 UserTable,Family,Qualifier:Permission 
  
  mapred Security,f1,c1: [Permission: 
 actions=READ,WRITE] 
 hbase(main):004:0 put 'Security', 'r6', 'f1:c1', 'v9'
 0 row(s) in 0.0590 seconds
 hbase(main):005:0 put 'Security', 'r6', 'f1:c1', 'v10'
 0 row(s) in 0.0040 seconds
 hbase(main):006:0 compact 'Security'
 0 row(s) in 0.0260 seconds
 {code}
 Maybe we can add permission check in the preCompactSelection() ?

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

[jira] [Updated] (HBASE-6192) Document ACL matrix in the book

2012-06-27 Thread Laxman (JIRA)


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

Laxman updated HBASE-6192:
--

Status: Patch Available  (was: Open)

 Document ACL matrix in the book
 ---

 Key: HBASE-6192
 URL: https://issues.apache.org/jira/browse/HBASE-6192
 Project: HBase
  Issue Type: Sub-task
  Components: documentation, security
Affects Versions: 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: documentaion, security
 Attachments: HBase Security-ACL Matrix.pdf, HBase Security-ACL 
 Matrix.pdf, HBase Security-ACL Matrix.pdf, HBase Security-ACL Matrix.xls, 
 HBase Security-ACL Matrix.xls, HBase Security-ACL Matrix.xls


 We have an excellent matrix at 
 https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf
  for ACL. Once the changes are done, we can adapt that and put it in the 
 book, also add some more documentation about the new authorization features. 

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

[jira] [Updated] (HBASE-6253) Dont allow user to disable/drop _acl_ table

2012-06-25 Thread Laxman (JIRA)


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

Laxman updated HBASE-6253:
--

Status: Patch Available  (was: Open)

Moving to PA.

 Dont allow user to disable/drop _acl_ table
 ---

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Gopinathan A
  Labels: security
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch, HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

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

[jira] [Commented] (HBASE-6253) Dont allow user to disable/drop _acl_ table

2012-06-25 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13400294#comment-13400294
 ] 

Laxman commented on HBASE-6253:
---

should we consider disallowing all DDL operations (add/delete/modify column)?
with online schema change, its not mandatory that we need to diable the table.
that means, we can drop the columns of acl table even now.


 Dont allow user to disable/drop _acl_ table
 ---

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Gopinathan A
  Labels: security
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch, HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

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

[jira] [Commented] (HBASE-6253) Dont allow user to disable/drop _acl_ table

2012-06-25 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13400296#comment-13400296
 ] 

Laxman commented on HBASE-6253:
---

by DDL i consider : AddColumn, ModifyColumn, DeleteColumn, EnableTable, 
DisableTable, ModifyTable, DeleteTable

Reference: ACL matrix available @ HBASE-6192


 Dont allow user to disable/drop _acl_ table
 ---

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Gopinathan A
  Labels: security
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch, HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

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

[jira] [Commented] (HBASE-5352) ACL improvements

2012-06-25 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13400591#comment-13400591
]

Laxman commented on HBASE-5352:
---

Patch available for review : HBASE-6257
Please review.

ACL improvements

Key: HBASE-5352
URL: https://issues.apache.org/jira/browse/HBASE-5352
Project: HBase
Issue Type: Improvement
Components: security
Affects Versions: 0.92.1, 0.94.0
Reporter: Enis Soztutar
Assignee: Enis Soztutar

In this issue I would like to open discussion for a few minor ACL related
improvements. The proposed changes are as follows:
1. Introduce something like
AccessControllerProtocol.checkPermissions(Permission[] permissions) API, so
that clients can check access rights before carrying out the operations. We
need this kind of operation for HCATALOG-245, which introduces authorization
providers for hbase over hcat. We cannot use getUserPermissions() since it
requires ADMIN permissions on the global/table level.
2. getUserPermissions(tableName)/grant/revoke and drop/modify table
operations should not check for global CREATE/ADMIN rights, but table
CREATE/ADMIN rights. The reasoning is that if a user is able to admin or read
from a table, she should be able to read the table's permissions. We can
choose whether we want only READ or ADMIN permissions for
getUserPermission(). Since we check for global permissions first for table
permissions, configuring table access using global permissions will continue
to work.
3. Grant/Revoke global permissions - HBASE-5342 (included for completeness)
From all 3, we may want to backport the first one to 0.92 since without it,
Hive/Hcatalog cannot use Hbase's authorization mechanism effectively.
I will create subissues and convert HBASE-5342 to a subtask when we get some
feedback, and opinions for going further.

[jira] [Updated] (HBASE-6192) Document ACL matrix in the book

2012-06-25 Thread Laxman (JIRA)


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

Laxman updated HBASE-6192:
--

Attachment: HBase Security-ACL Matrix.xls
HBase Security-ACL Matrix.pdf

@Stack, attached the updated matrix. Please review.


 Document ACL matrix in the book
 ---

 Key: HBASE-6192
 URL: https://issues.apache.org/jira/browse/HBASE-6192
 Project: HBase
  Issue Type: Sub-task
  Components: documentation, security
Affects Versions: 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: documentaion, security
 Attachments: HBase Security-ACL Matrix.pdf, HBase Security-ACL 
 Matrix.pdf, HBase Security-ACL Matrix.pdf, HBase Security-ACL Matrix.xls, 
 HBase Security-ACL Matrix.xls, HBase Security-ACL Matrix.xls


 We have an excellent matrix at 
 https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf
  for ACL. Once the changes are done, we can adapt that and put it in the 
 book, also add some more documentation about the new authorization features. 

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

[jira] [Updated] (HBASE-6257) Avoid unnecessary flush compact on Meta in admin.rb.

2012-06-24 Thread Laxman (JIRA)


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

Laxman updated HBASE-6257:
--

Attachment: HBASE-6257.patch

 Avoid unnecessary flush  compact on Meta in admin.rb.
 --

 Key: HBASE-6257
 URL: https://issues.apache.org/jira/browse/HBASE-6257
 Project: HBase
  Issue Type: Sub-task
  Components: security, shell
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: security
 Attachments: HBASE-6257.patch


 Discussed on dev list.
 When we drop a table or a group of tables via shell it flushes and triggers 
 major compaction on .META.
 drop requires a 'C' on table
 flush  compact requires 'A' on meta table
 So, drop will fail even if a user has sufficient permissions.

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

[jira] [Updated] (HBASE-6257) Avoid unnecessary flush compact on Meta in admin.rb.

2012-06-24 Thread Laxman (JIRA)


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

Laxman updated HBASE-6257:
--

Status: Patch Available  (was: Open)

 Avoid unnecessary flush  compact on Meta in admin.rb.
 --

 Key: HBASE-6257
 URL: https://issues.apache.org/jira/browse/HBASE-6257
 Project: HBase
  Issue Type: Sub-task
  Components: security, shell
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: security
 Attachments: HBASE-6257.patch


 Discussed on dev list.
 When we drop a table or a group of tables via shell it flushes and triggers 
 major compaction on .META.
 drop requires a 'C' on table
 flush  compact requires 'A' on meta table
 So, drop will fail even if a user has sufficient permissions.

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

[jira] [Updated] (HBASE-6253) Dont allow user to disable/drop _acl_ table

2012-06-24 Thread Laxman (JIRA)


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

Laxman updated HBASE-6253:
--

  Component/s: security
Affects Version/s: 0.94.1
   0.96.0
   Labels: security  (was: )

 Dont allow user to disable/drop _acl_ table
 ---

 Key: HBASE-6253
 URL: https://issues.apache.org/jira/browse/HBASE-6253
 Project: HBase
  Issue Type: Bug
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Gopinathan A
  Labels: security
 Fix For: 0.94.1

 Attachments: HBASE-6253.patch


 Currently HTableDescriptor.isLegalTableName API doesn't check for the _acl_ 
 table name, due to this user can able to disable/enable/drop/create the acl 
 table. 

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

[jira] [Assigned] (HBASE-6246) Admin.move() without specifying destination calls am.unassign() and does not go through AccessController.

2012-06-22 Thread Laxman (JIRA)


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

Laxman reassigned HBASE-6246:
-

Assignee: Laxman

 Admin.move() without specifying destination calls am.unassign() and does not 
 go through AccessController.
 -

 Key: HBASE-6246
 URL: https://issues.apache.org/jira/browse/HBASE-6246
 Project: HBase
  Issue Type: Bug
  Components: coprocessors, security
Affects Versions: 0.94.0, 0.94.1
Reporter: ramkrishna.s.vasudevan
Assignee: Laxman
  Labels: coprocessors, security
 Fix For: 0.94.1


 {code}
 if (destServerName == null || destServerName.length == 0) {
   LOG.info(Passed destination servername is null/empty so  +
 choosing a server at random);
   this.assignmentManager.clearRegionPlan(hri);
   // Unassign will reassign it elsewhere choosing random server.
   this.assignmentManager.unassign(hri);
 {code}
 I think we should go through security to see if there is sufficient 
 permissions to do this operation?

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

[jira] [Updated] (HBASE-6252) TABLE ADMIN should be allowed to do assign, unassign move as these are table level operations.

2012-06-21 Thread Laxman (JIRA)


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

Laxman updated HBASE-6252:
--

Attachment: HBASE-6252.patch

 TABLE ADMIN should be allowed to do assign, unassign  move as these are 
 table level operations.
 

 Key: HBASE-6252
 URL: https://issues.apache.org/jira/browse/HBASE-6252
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
 Attachments: HBASE-6252.patch




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

[jira] [Updated] (HBASE-6252) TABLE ADMIN should be allowed to do assign, unassign move as these are table level operations.

2012-06-21 Thread Laxman (JIRA)


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

Laxman updated HBASE-6252:
--

Status: Patch Available  (was: Open)

Attached the patch for review.
Includes another small change for private api requiredPermission.


 TABLE ADMIN should be allowed to do assign, unassign  move as these are 
 table level operations.
 

 Key: HBASE-6252
 URL: https://issues.apache.org/jira/browse/HBASE-6252
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
 Attachments: HBASE-6252.patch




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

[jira] [Assigned] (HBASE-6249) Apply ACLs to new bulk load hooks

2012-06-21 Thread Laxman (JIRA)


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

Laxman reassigned HBASE-6249:
-

Assignee: Laxman

 Apply ACLs to new bulk load hooks
 -

 Key: HBASE-6249
 URL: https://issues.apache.org/jira/browse/HBASE-6249
 Project: HBase
  Issue Type: Sub-task
Reporter: Andrew Purtell
Assignee: Laxman

 HBASE-6224 adds coprocessor hooks for bulk loading. This should require table 
 WRITE permission.

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

[jira] [Created] (HBASE-6257) Avoid unnecessary flush compact on Meta in admin.rb.

2012-06-21 Thread Laxman (JIRA)

Laxman created HBASE-6257:
-

 Summary: Avoid unnecessary flush  compact on Meta in admin.rb.
 Key: HBASE-6257
 URL: https://issues.apache.org/jira/browse/HBASE-6257
 Project: HBase
  Issue Type: Sub-task
  Components: security, shell
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman


Discussed on dev list.

When we drop a table or a group of tables via shell it flushes and triggers 
major compaction on .META.

drop requires a 'C' on table
flush  compact requires 'A' on meta table

So, drop will fail even if a user has sufficient permissions.


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

[jira] [Commented] (HBASE-4246) Cluster with too many regions cannot withstand some master failover scenarios

2012-06-20 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-4246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397290#comment-13397290
]

Laxman commented on HBASE-4246:
---

This may come in latest version also as we didn't change the znode hierarchy of
the unassigned regions. As mentioned in linked issue, there is a cap on packet
length. We can't read/write huge data in a single packet.

IMO, to resolve this we need to do *either of the following*.

* In HBASE: We can use hierarchical structure.
HDFS datanode follows similar strategy. It keeps block files in different sub
directories to avoid FS lookup latency.

* In ZooKeeper: Increase the limit. What is reasonable?
We have tried this out in some other project but it has the side effects. When
we tried read/write huge data from ZooKeeper, clients occassionally gets
disconnected. This is sequential request processing. Please check out the
related discussions @

http://mail-archives.apache.org/mod_mbox/zookeeper-user/201007.mbox/%3cc85a33ec.3a46a%25maha...@yahoo-inc.com%3E

Following JIRA and discussion also applicable in current scenario.
http://mail-archives.apache.org/mod_mbox/zookeeper-user/201104.mbox/%3cffa3bdb6-1c83-42b9-b2a0-767513462...@me.com%3E
https://issues.apache.org/jira/browse/ZOOKEEPER-1049

Cluster with too many regions cannot withstand some master failover scenarios
-

Key: HBASE-4246
URL: https://issues.apache.org/jira/browse/HBASE-4246
Project: HBase
Issue Type: Bug
Components: master, zookeeper
Affects Versions: 0.90.4
Reporter: Todd Lipcon
Priority: Critical
Fix For: 0.96.0

We ran into the following sequence of events:
- master startup failed after only ROOT had been assigned (for another reason)
- restarted the master without restarting other servers. Since there was at
least one region assigned, it went through the failover code path
- master scanned META and inserted every region into /hbase/unassigned in ZK.
- then, it called listChildren on the /hbase/unassigned znode, and crashed
with Packet len6080218 is out of range! since the IPC response was larger
than the default maximum.

[jira] [Commented] (HBASE-5352) ACL improvements

2012-06-20 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397772#comment-13397772
]

Laxman commented on HBASE-5352:
---

Patch available for: HBASE-6209, HBASE-6238, HBASE-6192
Please review.

ACL improvements

[jira] [Updated] (HBASE-6246) Admin.move() without specifying destination calls am.unassign() and does not go through AccessController.

2012-06-20 Thread Laxman (JIRA)


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

Laxman updated HBASE-6246:
--

  Component/s: coprocessors
Affects Version/s: 0.94.1
   0.94.0
   Labels: coprocessors security  (was: )

Seems to be 0.94 specific issue. Code looks good in trunk.


 Admin.move() without specifying destination calls am.unassign() and does not 
 go through AccessController.
 -

 Key: HBASE-6246
 URL: https://issues.apache.org/jira/browse/HBASE-6246
 Project: HBase
  Issue Type: Bug
  Components: coprocessors, security
Affects Versions: 0.94.0, 0.94.1
Reporter: ramkrishna.s.vasudevan
  Labels: coprocessors, security

 {code}
 if (destServerName == null || destServerName.length == 0) {
   LOG.info(Passed destination servername is null/empty so  +
 choosing a server at random);
   this.assignmentManager.clearRegionPlan(hri);
   // Unassign will reassign it elsewhere choosing random server.
   this.assignmentManager.unassign(hri);
 {code}
 I think we should go through security to see if there is sufficient 
 permissions to do this operation?

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

[jira] [Created] (HBASE-6252) TABLE ADMIN should be allowed to do assign, unassign move as these are table level operations.

2012-06-20 Thread Laxman (JIRA)

Laxman created HBASE-6252:
-

 Summary: TABLE ADMIN should be allowed to do assign, unassign  
move as these are table level operations.
 Key: HBASE-6252
 URL: https://issues.apache.org/jira/browse/HBASE-6252
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman




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

[jira] [Commented] (HBASE-5352) ACL improvements

2012-06-20 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13398215#comment-13398215
]

Laxman commented on HBASE-5352:
---

One observation related to operation vs ACL in our [Ram Laxman] discussion
today.

HBASE-6252 : TABLE ADMIN should be allowed to do assign, unassign move as
these are table level operations.

Any other opinion?

ACL improvements

[jira] [Commented] (HBASE-4791) Allow Secure Zookeeper JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

2012-06-19 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13396565#comment-13396565
 ] 

Laxman commented on HBASE-4791:
---

@Matt, Thanks for your quick response and patience.

Configuration.setConfiguration - Doesn't seems to be a clean approach. 
What happens when you want to use multiple ZK clusters from same ZK client? 
Other problem with this approach is concurrency issues. No?

Think of the following scenario from a HBase client application which accesses 
HBase and ZooKeeper for various puposes.

Thread-1 (HBase Client thread)
Step #1.1: oldConfig1 = Configuration.getConfiguration
Step #1.2: Configuration.setConfiguration(newConfig1)
Step #1.3: Initialize Do some work
Step #1.4: Configuration.setConfiguration(oldConfig1)

Thread-2 (Application specific thread)
Step #2.1: oldConfig2 = Configuration.getConfiguration
Step #2.2: Configuration.setConfiguration(newConfig2)
Step #2.3: Establish ZK Connection  do some work
Step #2.4: Configuration.setConfiguration(oldConfig2)

Will you be able to predict the behavior here when both of the threads run 
simultaneously?
Note that synchroniation also may not help as Thread-1 is HBase specific and 
Thread-2  Application specific.

What's your opinion on providing this as part of ZooKeeper client code allowing 
clients to configure thru constructor.

ZooKeeper(conf) - conf may be Map/ZKConfig/Properties/some other better data 
structure.


 Allow Secure Zookeeper JAAS configuration to be programmatically set (rather 
 than only by reading JAAS configuration file)
 --

 Key: HBASE-4791
 URL: https://issues.apache.org/jira/browse/HBASE-4791
 Project: HBase
  Issue Type: Improvement
  Components: security, zookeeper
Reporter: Eugene Koontz
Assignee: Eugene Koontz
  Labels: security, zookeeper
 Attachments: DemoConfig.java, HBASE-4791-v0.patch


 In the currently proposed fix for HBASE-2418, there must be a JAAS file 
 specified in System.setProperty(java.security.auth.login.config). 
 However, it might be preferable to construct a JAAS configuration 
 programmatically, as is done with secure Hadoop (see 
 https://github.com/apache/hadoop-common/blob/a48eceb62c9b5c1a5d71ee2945d9eea2ed62527b/src/java/org/apache/hadoop/security/UserGroupInformation.java#L175).
 This would have the benefit of avoiding a usage of a system property setting, 
 and allow instead an HBase-local configuration setting. 

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

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-19 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13396568#comment-13396568
 ] 

Laxman commented on HBASE-6188:
---

Thanks Andy. I didn't notice TEST_UTIL.waitTableAvailable earlier.

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, 
 HBASE-6188.3.patch, HBASE-6188.4.patch, HBASE-6188.patch, 
 org.apache.hadoop.hbase.security.access.TestAccessController.txt


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Commented] (HBASE-6229) AM.assign() should not set table state to ENABLED directly.

2012-06-19 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13396629#comment-13396629
 ] 

Laxman commented on HBASE-6229:
---

small nit

{code}
+  private boolean isNotEnabledorEnablingTable(final String tableName) {
+return !zkTable.isEnablingTable(tableName)  
!zkTable.isEnabledTable(tableName);
+  }
{code}

A separate method method may not be required for one liner. 

 AM.assign() should not set table state to ENABLED directly.
 ---

 Key: HBASE-6229
 URL: https://issues.apache.org/jira/browse/HBASE-6229
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.2, 0.94.1
Reporter: rajeshbabu
Assignee: rajeshbabu
 Fix For: 0.96.0, 0.94.1, 0.92.3

 Attachments: HBASE-6229_94.patch, HBASE-6229_94_1.patch, 
 HBASE-6229_trunk.patch, HBASE-6229_trunk_1.patch


 In case of assign from EnableTableHandler table state is ENABLING. Any how 
 EnableTableHandler will set ENABLED after assigning all the the table 
 regions. If we try to set to ENABLED directly then client api may think 
 ENABLE table is completed. When we have a case like all the regions are added 
 directly into META and we call assignRegion then we need to make the table 
 ENABLED.  Hence in such case the table will not be in ENABLING or ENABLED 
 state.

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

[jira] [Created] (HBASE-6238) Grant on Meta Table is not taking affect.

2012-06-19 Thread Laxman (JIRA)

Laxman created HBASE-6238:
-

 Summary: Grant on Meta Table is not taking affect.
 Key: HBASE-6238
 URL: https://issues.apache.org/jira/browse/HBASE-6238
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman


User is not able to perform authorized operations on Meta.


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

[jira] [Commented] (HBASE-6238) Grant on Meta Table is not taking affect.

2012-06-19 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13396678#comment-13396678
 ] 

Laxman commented on HBASE-6238:
---

Seems to be problem following code snippet in 
AccessControlLists.getTablePermissions(Configuration, byte[])

{noformat}
/* TODO: -ROOT- and .META. cannot easily be handled because they must be
 * online before _acl_ table.  Can anything be done here?
 */
if (Bytes.equals(tableName, HConstants.ROOT_TABLE_NAME) ||
Bytes.equals(tableName, HConstants.META_TABLE_NAME)) {
  return ArrayListMultimap.create(0,0);
}
{noformat}

I don't see a scenario why special handling ROOT  META tables are required.

Can this snippet be removed or you see any problem?

 Grant on Meta Table is not taking affect.
 -

 Key: HBASE-6238
 URL: https://issues.apache.org/jira/browse/HBASE-6238
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security

 User is not able to perform authorized operations on Meta.

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

[jira] [Commented] (HBASE-6209) ACL Corrections for AccessControllerProtocol apis

2012-06-19 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13396984#comment-13396984
 ] 

Laxman commented on HBASE-6209:
---

On closure look, checkPermissions need not be corrected.

 ACL Corrections for AccessControllerProtocol apis
 -

 Key: HBASE-6209
 URL: https://issues.apache.org/jira/browse/HBASE-6209
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1


 APIs provided in AccessController are authorized against global-admin 
 permissions. Instead we need to check for table-admin level permissions.
 Edit: Append operation also has no authorization check. We can update it 
 together.

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

[jira] [Updated] (HBASE-6209) ACL Corrections for AccessControllerProtocol apis

2012-06-19 Thread Laxman (JIRA)


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

Laxman updated HBASE-6209:
--

Status: Patch Available  (was: Open)

patch includes ACL corrections for grant, revoke, getUserPermissions and Append.

Please review.

 ACL Corrections for AccessControllerProtocol apis
 -

 Key: HBASE-6209
 URL: https://issues.apache.org/jira/browse/HBASE-6209
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6209.patch


 APIs provided in AccessController are authorized against global-admin 
 permissions. Instead we need to check for table-admin level permissions.
 Edit: Append operation also has no authorization check. We can update it 
 together.

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

[jira] [Updated] (HBASE-6209) ACL Corrections for AccessControllerProtocol apis

2012-06-19 Thread Laxman (JIRA)


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

Laxman updated HBASE-6209:
--

Attachment: HBASE-6209.patch

 ACL Corrections for AccessControllerProtocol apis
 -

 Key: HBASE-6209
 URL: https://issues.apache.org/jira/browse/HBASE-6209
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6209.patch


 APIs provided in AccessController are authorized against global-admin 
 permissions. Instead we need to check for table-admin level permissions.
 Edit: Append operation also has no authorization check. We can update it 
 together.

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

[jira] [Commented] (HBASE-6238) Grant on Meta Table is not taking affect.

2012-06-19 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397004#comment-13397004
]

Laxman commented on HBASE-6238:
---

context:
http://mail-archives.apache.org/mod_mbox/hbase-dev/201206.mbox/%3CCA%2BRK%3D_C%3D0JnJ0CCJVYCicrWCn6gPn1zoBDahUP6xaKGZPYDBVA%40mail.gmail.com%3E

Before correcting in ruby scripts, I tried to edit/flush META after giving
permissions appropriate permissions on META table to a user (non-super user). I
was expecting the operation to succeed. But it didn't due to above piece of
code.

bq. What are the exceptions to that rule?
In one of our scenario, owner of a table needs to pre-create regions (=1000)
by directly adding entries to META flushes META.

If we remove the snippet of code which I quoted in my previous comments, META
will be treated as any other table.

Should we proceed with removing this piece of code?

Note: Irrespective of this change, we may still needs to correct the ruby
scripts as discussed on dev mailing list. Will file a JIRA separately.

Grant on Meta Table is not taking affect.
-

Key: HBASE-6238
URL: https://issues.apache.org/jira/browse/HBASE-6238
Project: HBase
Issue Type: Sub-task
Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
Labels: acl, security

User is not able to perform authorized operations on Meta.

[jira] [Updated] (HBASE-6238) Grant on Meta Table is not taking affect.

2012-06-19 Thread Laxman (JIRA)


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

Laxman updated HBASE-6238:
--

Attachment: HBASE-6238.patch

 Grant on Meta Table is not taking affect.
 -

 Key: HBASE-6238
 URL: https://issues.apache.org/jira/browse/HBASE-6238
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Attachments: HBASE-6238.patch


 User is not able to perform authorized operations on Meta.

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

[jira] [Updated] (HBASE-6238) Grant on Meta Table is not taking affect.

2012-06-19 Thread Laxman (JIRA)


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

Laxman updated HBASE-6238:
--

Status: Patch Available  (was: Open)

 Grant on Meta Table is not taking affect.
 -

 Key: HBASE-6238
 URL: https://issues.apache.org/jira/browse/HBASE-6238
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Attachments: HBASE-6238.patch


 User is not able to perform authorized operations on Meta.

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

[jira] [Updated] (HBASE-6192) Document ACL matrix in the book

2012-06-19 Thread Laxman (JIRA)


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

Laxman updated HBASE-6192:
--

Attachment: HBase Security-ACL Matrix.xls
HBase Security-ACL Matrix.pdf

 Document ACL matrix in the book
 ---

 Key: HBASE-6192
 URL: https://issues.apache.org/jira/browse/HBASE-6192
 Project: HBase
  Issue Type: Sub-task
  Components: documentation, security
Affects Versions: 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: documentaion, security
 Attachments: HBase Security-ACL Matrix.pdf, HBase Security-ACL 
 Matrix.pdf, HBase Security-ACL Matrix.xls, HBase Security-ACL Matrix.xls


 We have an excellent matrix at 
 https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf
  for ACL. Once the changes are done, we can adapt that and put it in the 
 book, also add some more documentation about the new authorization features. 

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

[jira] [Commented] (HBASE-6222) Add per-KeyValue Security

2012-06-18 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393676#comment-13393676
]

Laxman commented on HBASE-6222:
---

Good to see lot of interest and discussion in this.

I couldn't understand the above discussion completely.
But, I've some basic questions.
1) Do we really have any known use-cases for KV based access control?
2) Does scalability affected badly for the users who needs at KV level access
control?

How about other approach of supporting access control through *HBase views*?
If we want to restrict access for a CF/CQ and a set of rows to a user/group
then create a view for that set and control access through view.

It's just an idea based on my understanding of RDBMS (Oracle). Not really sure
if this is really feasible in HBase. Please respond with use-cases and comments.

Add per-KeyValue Security
-

Key: HBASE-6222
URL: https://issues.apache.org/jira/browse/HBASE-6222
Project: HBase
Issue Type: New Feature
Components: security
Reporter: stack

Saw an interesting article:
http://www.fiercegovernmentit.com/story/sasc-accumulo-language-pro-open-source-say-proponents/2012-06-14
The Senate Armed Services Committee version of the fiscal 2013 national
defense authorization act (S. 3254) would require DoD agencies to foreswear
the Accumulo NoSQL database after Sept. 30, 2013, unless the DoD CIO
certifies that there exists either no viable commercial open source database
with security features comparable to [Accumulo] (such as the HBase or
Cassandra databases)...
Not sure what a 'commercial open source database' is, and I'm not sure whats
going on in the article, but tra-la-la'ing, if we had per-KeyValue 'security'
like Accumulo's, we might put ourselves in the running for federal
contributions?

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-18 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393685#comment-13393685
 ] 

Laxman commented on HBASE-6188:
---

From the log attached.
{noformat}
at 
org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:347)
at 
org.apache.hadoop.hbase.security.access.TestAccessController.setupBeforeClass(TestAccessController.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{noformat}

From TestAccessController.setupBeforeClass()
{code}
HTableDescriptor htd = new HTableDescriptor(TEST_TABLE);
htd.addFamily(new HColumnDescriptor(TEST_FAMILY));
htd.setOwner(USER_OWNER);
admin.createTable(htd);
{code}

This indicates acl is table is not yet online by the time of creation of test 
table.
A small delay (sleep for 1 sec) after starting the cluster may help to resolve 
this intermittent test failure.

Andy, I couldn't verify this its running fine in my local and QA build. Any 
other suggestions apart from introducing a delay?


 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, 
 HBASE-6188.3.patch, HBASE-6188.4.patch, HBASE-6188.patch, 
 org.apache.hadoop.hbase.security.access.TestAccessController.txt


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Commented] (HBASE-6222) Add per-KeyValue Security

2012-06-18 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13395815#comment-13395815
]

Laxman commented on HBASE-6222:
---

bq. The basic premise here is to be on-par security wise with Accumulo. That is
the use-case.

IMHO, that's one implementation but not use-case. Definitely, Accumulo would
have some straight use-case. Do we that use-case? Based on use-case, we can
brainstorm on different approaches (KV level, Views, something else may be).

bq. where do you see this could affect the performance?

I have following concern w.r.to *scalability*.

* With current implementation, ACLs are cached. With cell level, it may grow
heavily.
* Please take a look @AccessController.permissionGranted method. We need to
call this method(+some more checks for KV based) for every KV. This may become
a hotspot when we introduce KV based access control.

We are currently evaluating performance with security enabled. Soon, I will
share our report.

bq. Think of blocking access to some columns differently across many rows.
I agree. Can you please explain how do we solve this with a traditional RDBMS
like Oracle.

*Note:* I definitely don't want to bring up the well known discussion SQL vs
NOSQL here and I'm only trying to understand the use-case as a HBase
user/developer. Only point I want to put forward is we should have proper
understanding of use-case and user before we start on a approach/solution.

Add per-KeyValue Security
-

Key: HBASE-6222
URL: https://issues.apache.org/jira/browse/HBASE-6222
Project: HBase
Issue Type: New Feature
Components: security
Reporter: stack

[jira] [Commented] (HBASE-6222) Add per-KeyValue Security

2012-06-18 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13395856#comment-13395856
 ] 

Laxman commented on HBASE-6222:
---

Thanks for clarification Anoop. So, one of the concerns w.r.to cache can be 
ruled out for further discussion.

 Add per-KeyValue Security
 -

 Key: HBASE-6222
 URL: https://issues.apache.org/jira/browse/HBASE-6222
 Project: HBase
  Issue Type: New Feature
  Components: security
Reporter: stack

 Saw an interesting article: 
 http://www.fiercegovernmentit.com/story/sasc-accumulo-language-pro-open-source-say-proponents/2012-06-14
 The  Senate Armed Services Committee version of the fiscal 2013 national 
 defense authorization act (S. 3254) would require DoD agencies to foreswear 
 the Accumulo NoSQL database after Sept. 30, 2013, unless the DoD CIO 
 certifies that there exists either no viable commercial open source database 
 with security features comparable to [Accumulo] (such as the HBase or 
 Cassandra databases)...
 Not sure what a 'commercial open source database' is, and I'm not sure whats 
 going on in the article, but tra-la-la'ing, if we had per-KeyValue 'security' 
 like Accumulo's, we might put ourselves in the running for federal 
 contributions?

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

[jira] [Commented] (HBASE-4791) Allow Secure Zookeeper JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

2012-06-18 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13395875#comment-13395875
]

Laxman commented on HBASE-4791:
---

I understand Matt. Looks good.
iiuc, your suggestion is to ZooKeeper clients(like HBase) has to set this via
Configuration.setConfiguration.

Following are points of discussion if we go with this approach.

* For every ZooKeeper client connection we need to do this
Configuration.setConfiguration.
* Configuration.setConfiguration overwrites the default configuration. May
cause problems, if client application also expects this way.

Allow Secure Zookeeper JAAS configuration to be programmatically set (rather
than only by reading JAAS configuration file)
--

Key: HBASE-4791
URL: https://issues.apache.org/jira/browse/HBASE-4791
Project: HBase
Issue Type: Improvement
Components: security, zookeeper
Reporter: Eugene Koontz
Assignee: Eugene Koontz
Labels: security, zookeeper
Attachments: DemoConfig.java, HBASE-4791-v0.patch

In the currently proposed fix for HBASE-2418, there must be a JAAS file
specified in System.setProperty(java.security.auth.login.config).
However, it might be preferable to construct a JAAS configuration
programmatically, as is done with secure Hadoop (see
https://github.com/apache/hadoop-common/blob/a48eceb62c9b5c1a5d71ee2945d9eea2ed62527b/src/java/org/apache/hadoop/security/UserGroupInformation.java#L175).
This would have the benefit of avoiding a usage of a system property setting,
and allow instead an HBase-local configuration setting.

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-17 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Attachment: HBASE-6188.4.patch

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, 
 HBASE-6188.3.patch, HBASE-6188.4.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Commented] (HBASE-4791) Allow Secure Zookeeper JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

2012-06-17 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393665#comment-13393665
 ] 

Laxman commented on HBASE-4791:
---

@Matt, zookeeper.sasl.clientconfig is only for client context name. 
Basically, in a JAAS configuration we can have multiple sections like below one.

{noformat}
Client {   
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true   
useTicketCache=false
keyTab=/hbase/master/conf/hbase.keytab   
principal=hbase/had...@hadoop.com;
}; 
{noformat}

ZOOKEEPER-1373 enables the user to configure a specific section from JAAS to be 
used for zookeeper and *it still requires the configuration 
java.security.auth.login.config*. But, current jira is mainly for allowing 
the JAAS can be configured via programmatically and avoid configuring via 
system property. So, this requires changes on zookeeper like allowing client to 
provide a config object or so...

Correct me if my understanding is wrong.

 Allow Secure Zookeeper JAAS configuration to be programmatically set (rather 
 than only by reading JAAS configuration file)
 --

 Key: HBASE-4791
 URL: https://issues.apache.org/jira/browse/HBASE-4791
 Project: HBase
  Issue Type: Improvement
  Components: security, zookeeper
Reporter: Eugene Koontz
Assignee: Eugene Koontz
  Labels: security, zookeeper
 Attachments: HBASE-4791-v0.patch


 In the currently proposed fix for HBASE-2418, there must be a JAAS file 
 specified in System.setProperty(java.security.auth.login.config). 
 However, it might be preferable to construct a JAAS configuration 
 programmatically, as is done with secure Hadoop (see 
 https://github.com/apache/hadoop-common/blob/a48eceb62c9b5c1a5d71ee2945d9eea2ed62527b/src/java/org/apache/hadoop/security/UserGroupInformation.java#L175).
 This would have the benefit of avoiding a usage of a system property setting, 
 and allow instead an HBase-local configuration setting. 

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

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-16 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13393391#comment-13393391
 ] 

Laxman commented on HBASE-6188:
---

Thanks for pointing it out Andy. I couldn't notice these test failures as they 
are intermittent failures.
Even in QA bot build also passing. I will correct this.

{quote}
The new code in postCreateTable must make a special case for the ACL table. 
It's not possible to call AccessControlLists.addUserPermission before the ACL 
table is deployed, i.e. created.
{quote}

Introducing a check like below is fine?

{code}
  public void postCreateTable(ObserverContextMasterCoprocessorEnvironment c,
  HTableDescriptor desc, HRegionInfo[] regions) throws IOException {
if (!AccessControlLists.isAclTable(desc)) {
  String owner = desc.getOwnerString();
  // default the table owner to current user, if not specified.
  if (owner == null) owner = getActiveUser().getShortName();
  UserPermission userperm = new UserPermission(Bytes.toBytes(owner), 
desc.getName(), null,
  Action.values());
  
AccessControlLists.addUserPermission(c.getEnvironment().getConfiguration(), 
userperm);
}
  }
{code}

Apologies for the noise due to multiple submissions for this issue.

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-16 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Attachment: HBASE-6188.3.patch

Attached the new patch

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, 
 HBASE-6188.3.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Commented] (HBASE-6192) Document ACL matrix in the book

2012-06-14 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294917#comment-13294917
 ] 

Laxman commented on HBASE-6192:
---

This matrix does not cover AccessControllerProtocol interface. I will add that 
too as this interface can be directly used by user. Will post the updated 
matrix. Please give your opinion.

 Document ACL matrix in the book
 ---

 Key: HBASE-6192
 URL: https://issues.apache.org/jira/browse/HBASE-6192
 Project: HBase
  Issue Type: Sub-task
  Components: documentation, security
Affects Versions: 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: documentaion, security
 Attachments: HBase Security-ACL Matrix.pdf, HBase Security-ACL 
 Matrix.xls


 We have an excellent matrix at 
 https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf
  for ACL. Once the changes are done, we can adapt that and put it in the 
 book, also add some more documentation about the new authorization features. 

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

[jira] [Created] (HBASE-6209) ACL Corrections corrections for AccessControllerProtocol apis

2012-06-14 Thread Laxman (JIRA)

Laxman created HBASE-6209:
-

 Summary: ACL Corrections corrections for AccessControllerProtocol 
apis
 Key: HBASE-6209
 URL: https://issues.apache.org/jira/browse/HBASE-6209
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
 Fix For: 0.96.0, 0.94.1


APIs provided in AccessController are authorized against global-admin 
permissions. Instead we need to check for table-admin level permissions.

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

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-14 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294943#comment-13294943
 ] 

Laxman commented on HBASE-6188:
---

All tests were passing in QA bot build.
https://builds.apache.org/job/PreCommit-HBASE-Build/2164//testReport/org.apache.hadoop.hbase.security.access/TestAccessController/

Please review.

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-5372) Table mutation operations should check table level rights, not global rights

2012-06-14 Thread Laxman (JIRA)

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

Laxman updated HBASE-5372:
--

Description: drop/modify/disable/enable etc table operations should not
check for global CREATE/ADMIN rights, but table CREATE/ADMIN rights. Since we
check for global permissions first for table permissions, configuring table
access using global permissions will continue to work. (was:
getUserPermissions(tableName)/grant/revoke and drop/modify table operations
should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN rights.
The reasoning is that if a user is able to admin or read from a table, she
should be able to read the table's permissions. We can choose whether we want
only READ or ADMIN permissions for getUserPermission(). Since we check for
global permissions first for table permissions, configuring table access using
global permissions will continue to work. )

{quote}
getUserPermissions(tableName)/grant/revoke

The reasoning is that if a user is able to admin or read from a table, she
should be able to read the table's permissions. We can choose whether we want
only READ or ADMIN permissions for getUserPermission().
{quote}

ACL corrections for AccessController protocol apis will be addressed in
HBASE-6209.

Table mutation operations should check table level rights, not global rights
-

Key: HBASE-5372
URL: https://issues.apache.org/jira/browse/HBASE-5372
Project: HBase
Issue Type: Sub-task
Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
Labels: security
Fix For: 0.96.0, 0.94.1

Attachments: HBASE-5372.patch

drop/modify/disable/enable etc table operations should not check for global
CREATE/ADMIN rights, but table CREATE/ADMIN rights. Since we check for global
permissions first for table permissions, configuring table access using
global permissions will continue to work.

[jira] [Updated] (HBASE-6209) ACL Corrections for AccessControllerProtocol apis

2012-06-14 Thread Laxman (JIRA)


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

Laxman updated HBASE-6209:
--

 Labels: acl security  (was: security)
Summary: ACL Corrections for AccessControllerProtocol apis  (was: ACL 
Corrections corrections for AccessControllerProtocol apis)

 ACL Corrections for AccessControllerProtocol apis
 -

 Key: HBASE-6209
 URL: https://issues.apache.org/jira/browse/HBASE-6209
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1


 APIs provided in AccessController are authorized against global-admin 
 permissions. Instead we need to check for table-admin level permissions.

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

[jira] [Commented] (HBASE-6192) Document ACL matrix in the book

2012-06-14 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295435#comment-13295435
 ] 

Laxman commented on HBASE-6192:
---

Thanks stack. I'll update the matrix considering HBASE-6209. I'll do that.

 Document ACL matrix in the book
 ---

 Key: HBASE-6192
 URL: https://issues.apache.org/jira/browse/HBASE-6192
 Project: HBase
  Issue Type: Sub-task
  Components: documentation, security
Affects Versions: 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: documentaion, security
 Attachments: HBase Security-ACL Matrix.pdf, HBase Security-ACL 
 Matrix.xls


 We have an excellent matrix at 
 https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf
  for ACL. Once the changes are done, we can adapt that and put it in the 
 book, also add some more documentation about the new authorization features. 

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

[jira] [Updated] (HBASE-6209) ACL Corrections for AccessControllerProtocol apis

2012-06-14 Thread Laxman (JIRA)


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

Laxman updated HBASE-6209:
--

Description: 
APIs provided in AccessController are authorized against global-admin 
permissions. Instead we need to check for table-admin level permissions.

Edit: Append operation also has no authorization check. We can update it 
together.

  was:APIs provided in AccessController are authorized against global-admin 
permissions. Instead we need to check for table-admin level permissions.


 ACL Corrections for AccessControllerProtocol apis
 -

 Key: HBASE-6209
 URL: https://issues.apache.org/jira/browse/HBASE-6209
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1


 APIs provided in AccessController are authorized against global-admin 
 permissions. Instead we need to check for table-admin level permissions.
 Edit: Append operation also has no authorization check. We can update it 
 together.

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

[jira] [Commented] (HBASE-6209) ACL Corrections for AccessControllerProtocol apis

2012-06-14 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13295436#comment-13295436
 ] 

Laxman commented on HBASE-6209:
---

Thinking of following approach. 

grant, revoke, getUserPermissions, checkPermissions - All these apis needs to 
be authorized against CQ/CF/table/global admin permissions.

Append - WRITE

Any corrections required?

 ACL Corrections for AccessControllerProtocol apis
 -

 Key: HBASE-6209
 URL: https://issues.apache.org/jira/browse/HBASE-6209
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1


 APIs provided in AccessController are authorized against global-admin 
 permissions. Instead we need to check for table-admin level permissions.
 Edit: Append operation also has no authorization check. We can update it 
 together.

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

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-13 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294228#comment-13294228
 ] 

Laxman commented on HBASE-6188:
---

Andy, Thanks for through review.
Updated with my comments in review board.


 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-13 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294514#comment-13294514
]

Laxman commented on HBASE-6188:
---

bq. 1) In PostCreate - We can grant CRWA permissions to the current user(i.e.
owner).

I was thinking to ignoring the owner and PostCreate will make use of
getActiveUser() to get the requested user. But, as per your comments, i
understand that, we still need to consider owner to make it backward
compatible.

bq. Forgot to mention that also this needs to happen if the table owner is
changed via setOwner().

I think this needs to be handled in postModifyTable. But I can see that raises
some more questions.
* Should we revoke permissions for old owner? If yes, how do we track old owner
in postModify?

Please correct me if my understanding is incorrect.

Remove the concept of table owner
-

Key: HBASE-6188
URL: https://issues.apache.org/jira/browse/HBASE-6188
Project: HBase
Issue Type: Sub-task
Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
Labels: security
Fix For: 0.96.0, 0.94.1

Attachments: HBASE-6188.1.patch, HBASE-6188.patch

The table owner concept was a design simplification in the initial drop.
First, the design changes under review means only a user with GLOBAL CREATE
permission can create a table, which will probably be an administrator.
Then, granting implicit permissions may lead to oversights and it adds
unnecessary conditionals to our code. So instead the administrator with
GLOBAL CREATE permission should make the appropriate grants at table create
time.

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-13 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Status: Patch Available  (was: Open)

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-13 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294583#comment-13294583
 ] 

Laxman commented on HBASE-6188:
---

Attached the new patch after fixing the review comments.
This patch includes new testcases for owner and change of owner.

Please review.

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-13 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Attachment: HBASE-6188.2.patch

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-13 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Status: Open  (was: Patch Available)

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-6192) Document ACL matrix in the book

2012-06-13 Thread Laxman (JIRA)


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

Laxman updated HBASE-6192:
--

Attachment: HBase Security-ACL Matrix.xls
HBase Security-ACL Matrix.pdf

ACL Matrix attached in MS excel and pdf format. Feel free to modify if 
required. I'm not very sure where to include this matrix in hbase documentation.

 Document ACL matrix in the book
 ---

 Key: HBASE-6192
 URL: https://issues.apache.org/jira/browse/HBASE-6192
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.96.0
Reporter: Enis Soztutar
Assignee: Laxman
 Attachments: HBase Security-ACL Matrix.pdf, HBase Security-ACL 
 Matrix.xls


 We have an excellent matrix at 
 https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf
  for ACL. Once the changes are done, we can adapt that and put it in the 
 book, also add some more documentation about the new authorization features. 

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

[jira] [Updated] (HBASE-6192) Document ACL matrix in the book

2012-06-13 Thread Laxman (JIRA)


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

Laxman updated HBASE-6192:
--

  Component/s: documentation
Affects Version/s: 0.94.1
 Tags: documentation, hbase book
   Labels: documentaion security  (was: )

 Document ACL matrix in the book
 ---

 Key: HBASE-6192
 URL: https://issues.apache.org/jira/browse/HBASE-6192
 Project: HBase
  Issue Type: Sub-task
  Components: documentation, security
Affects Versions: 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: documentaion, security
 Attachments: HBase Security-ACL Matrix.pdf, HBase Security-ACL 
 Matrix.xls


 We have an excellent matrix at 
 https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf
  for ACL. Once the changes are done, we can adapt that and put it in the 
 book, also add some more documentation about the new authorization features. 

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

[jira] [Commented] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-12 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293379#comment-13293379
]

Laxman commented on HBASE-6092:
---

Thanks for review Andy.

bq. Please update the comments in the tests you added
Copy paste error. My mistake. Sorry.

Also, one more observation. We should throw back IOException from
RegionCoprocessorHost from pre/post split/flush/compact methods using:

{code}
org.apache.hadoop.hbase.coprocessor.CoprocessorHost.handleCoprocessorThrowable(CoprocessorEnvironment,
Throwable)
{code}

bq. -1 core tests.
Verified these testcases locally. And not relevant to the patch.

bq. -1 findbugs.
Verified the findbugs report. This patch does not introduce any findbugs.

Authorize flush, split, compact operations in AccessController
--

Key: HBASE-6092
URL: https://issues.apache.org/jira/browse/HBASE-6092
Project: HBase
Issue Type: Sub-task
Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
Labels: acl, security
Fix For: 0.96.0, 0.94.1

Attachments: HBASE-6092.patch

Currently, flush, split and compaction are not checked for authorization in
AccessController. With the current implementation any unauthorized client can
trigger these operations on a table.

[jira] [Updated] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-6092:
--

Status: Open  (was: Patch Available)

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6092.patch


 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Updated] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-6092:
--

Attachment: HBASE-6092.1.patch

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6092.1.patch, HBASE-6092.patch


 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Updated] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-6092:
--

Status: Patch Available  (was: Open)

New patch attached for review after fixing review comments and my observation.

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6092.1.patch, HBASE-6092.patch


 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Commented] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-12 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293570#comment-13293570
 ] 

Laxman commented on HBASE-6092:
---

bq. -1 findbugs
This patch does not introduce any findbugs.

bq. -1 core tests
Verified these testcases. Passing locally. Failures are not relevant to the 
patch.

Please review the patch.

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6092.1.patch, HBASE-6092.patch


 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Attachment: HBASE-6188.patch

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Attachments: HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Fix Version/s: 0.94.1
   0.96.0
Affects Version/s: 0.94.1
   0.96.0
   0.94.0
   Status: Patch Available  (was: Open)

Patch attached as per the approach discussed.
And this patch includes HBASE-6092 as that is not commited.

Please review.

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-4791) Allow Secure Zookeeper JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-4791:
--

Component/s: zookeeper
 security

 Allow Secure Zookeeper JAAS configuration to be programmatically set (rather 
 than only by reading JAAS configuration file)
 --

 Key: HBASE-4791
 URL: https://issues.apache.org/jira/browse/HBASE-4791
 Project: HBase
  Issue Type: Improvement
  Components: security, zookeeper
Reporter: Eugene Koontz
Assignee: Eugene Koontz
  Labels: security, zookeeper
 Attachments: HBASE-4791-v0.patch


 In the currently proposed fix for HBASE-2418, there must be a JAAS file 
 specified in System.setProperty(java.security.auth.login.config). 
 However, it might be preferable to construct a JAAS configuration 
 programmatically, as is done with secure Hadoop (see 
 https://github.com/apache/hadoop-common/blob/a48eceb62c9b5c1a5d71ee2945d9eea2ed62527b/src/java/org/apache/hadoop/security/UserGroupInformation.java#L175).
 This would have the benefit of avoiding a usage of a system property setting, 
 and allow instead an HBase-local configuration setting. 

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

[jira] [Commented] (HBASE-4791) Allow Secure Zookeeper JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

2012-06-12 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293797#comment-13293797
]

Laxman commented on HBASE-4791:
---

IMO, this requires a fix in zookeeper as it expects JAAS configuration provided
as a system property in ZooKeeperSaslClient. Changing that may not be so easy
due to following reason.

* ZooKeeper client doesn't expect any configuration. It just needs a quorum
string. So, introducing a configuration may introduce compatability issue.

I filed a similar hard-coding related issue ZOOKEEPER-1467.

Allow Secure Zookeeper JAAS configuration to be programmatically set (rather
than only by reading JAAS configuration file)
--

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-12 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293803#comment-13293803
 ] 

Laxman commented on HBASE-6188:
---

Test failures and findbugs are not relevant to the current patch.
Please review the patch.

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Status: Open  (was: Patch Available)

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Status: Patch Available  (was: Open)

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Updated] (HBASE-6188) Remove the concept of table owner

2012-06-12 Thread Laxman (JIRA)


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

Laxman updated HBASE-6188:
--

Attachment: HBASE-6188.1.patch

 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6188.1.patch, HBASE-6188.patch


 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Commented] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-12 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294158#comment-13294158
 ] 

Laxman commented on HBASE-6092:
---

Thanks Andy.

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6092.1.patch, HBASE-6092.patch


 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Updated] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-11 Thread Laxman (JIRA)


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

Laxman updated HBASE-6092:
--

Fix Version/s: 0.94.1
   0.96.0
Affects Version/s: 0.94.1
   0.96.0
   0.94.0
   Status: Patch Available  (was: Open)

Patch as per the above approach.

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6092.patch


 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Updated] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-11 Thread Laxman (JIRA)


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

Laxman updated HBASE-6092:
--

Attachment: HBASE-6092.patch

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-6092.patch


 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Commented] (HBASE-5947) Check for valid user/table/family/qualifier and acl state

2012-06-11 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292890#comment-13292890
 ] 

Laxman commented on HBASE-5947:
---

@Matt, any update on this issue?

 Check for valid user/table/family/qualifier and acl state
 -

 Key: HBASE-5947
 URL: https://issues.apache.org/jira/browse/HBASE-5947
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.92.1, 0.94.0, 0.96.0
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
  Labels: acl

 HBase Shell grant/revoke doesn't check for valid user or 
 table/family/qualifier so can you end up having rights for something that 
 doesn't exists.
 We might also want to ensure, upon table/column creation, that no entries are 
 already stored at the acl table. We might still have residual acl entries if 
 something goes wrong, in postDeleteTable(), postDeleteColumn().

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

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-11 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292939#comment-13292939
]

Laxman commented on HBASE-6188:
---

Thanks Ram for pitching in.

Andy, we definitely agree to your point. Just reiterating my previous comments.

{quote}
I agree with you Andy. But if we keep DisableTable/EnableTable permission with
ADMIN alone, to delete/modify a table a user should have both ADMIN and CREATE
permissions. ADMIN access to disable a table and CREATE access to delete/modify
the table. Or user with CREATE only access has to request the ADMIN user to
disable/enable the table before/after DDL.
{quote}

So, to delete a table requires two different users or one user with both
permissions. This is my only concern.

Thanks for clarification. Please provide your opinion of this.

CREATE -(DDL) CreateTable, AddColumn, DeleteColumn, DeleteTable, ModifyColumn,
ModifyTable
ADMIN - DisableTable, EnableTable

bq. it is a large subset of ADMIN permission.

Please note that above are two disjoint sets. That means, DDL operations can't
be done by ADMIN. Hope that should make them clean.

Remove the concept of table owner
-

Key: HBASE-6188
URL: https://issues.apache.org/jira/browse/HBASE-6188
Project: HBase
Issue Type: Sub-task
Components: security
Reporter: Andrew Purtell
Assignee: Laxman
Labels: security

[jira] [Commented] (HBASE-5947) Check for valid user/table/family/qualifier and acl state

2012-06-11 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292950#comment-13292950
 ] 

Laxman commented on HBASE-5947:
---

:) I just asked as I noticed parent issue can be closed if this issue is closed.

bq. But if you want take the ownership of this, go ahead!
I'm not comfortable with LDAP. Will check once and get back to you on this.
A brief approach may be helpful for me to understand.

 Check for valid user/table/family/qualifier and acl state
 -

 Key: HBASE-5947
 URL: https://issues.apache.org/jira/browse/HBASE-5947
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.92.1, 0.94.0, 0.96.0
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
  Labels: acl

 HBase Shell grant/revoke doesn't check for valid user or 
 table/family/qualifier so can you end up having rights for something that 
 doesn't exists.
 We might also want to ensure, upon table/column creation, that no entries are 
 already stored at the acl table. We might still have residual acl entries if 
 something goes wrong, in postDeleteTable(), postDeleteColumn().

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

[jira] [Commented] (HBASE-5352) ACL improvements

2012-06-11 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292972#comment-13292972
]

Laxman commented on HBASE-5352:
---

Request for review for subtask: HBASE-6092

ACL improvements

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-11 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293332#comment-13293332
 ] 

Laxman commented on HBASE-6188:
---

bq. CREATE -(DDL) CreateTable, AddColumn, DeleteColumn, DeleteTable, 
ModifyColumn, ModifyTable, DisableTable, EnableTable

bq. ADMIN - All of the above plus Flush, Split, Compact

Thanks a lot Andy. I will consider this.
I didn't consider flush, split and compact as the context is DDL.


 Remove the concept of table owner
 -

 Key: HBASE-6188
 URL: https://issues.apache.org/jira/browse/HBASE-6188
 Project: HBase
  Issue Type: Sub-task
  Components: security
Reporter: Andrew Purtell
Assignee: Laxman
  Labels: security

 The table owner concept was a design simplification in the initial drop.
 First, the design changes under review means only a user with GLOBAL CREATE 
 permission can create a table, which will probably be an administrator.
 Then, granting implicit permissions may lead to oversights and it adds 
 unnecessary conditionals to our code. So instead the administrator with 
 GLOBAL CREATE permission should make the appropriate grants at table create 
 time.

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

[jira] [Commented] (HBASE-5372) Table mutation operations should check table level rights, not global rights

2012-06-09 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292403#comment-13292403
 ] 

Laxman commented on HBASE-5372:
---

Thanks Andy.

 Table mutation operations should check table level rights, not global rights 
 -

 Key: HBASE-5372
 URL: https://issues.apache.org/jira/browse/HBASE-5372
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-5372.patch


 getUserPermissions(tableName)/grant/revoke and drop/modify table operations 
 should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN 
 rights. The reasoning is that if a user is able to admin or read from a 
 table, she should be able to read the table's permissions. We can choose 
 whether we want only READ or ADMIN permissions for getUserPermission(). Since 
 we check for global permissions first for table permissions, configuring 
 table access using global permissions will continue to work. 

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

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

2012-06-09 Thread Laxman (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292420#comment-13292420
]

Laxman commented on HBASE-6188:
---

I agree with you Andy. But if we keep DisableTable/EnableTable permission with
ADMIN alone, to delete/modify a table a user should have both ADMIN and CREATE
permissions. ADMIN access to disable a table and CREATE access to delete/modify
the table. Or user with CREATE only access has to request the ADMIN user to
disable/enable the table before/after DDL.

So, I feel its better to keep DDL permissions with CREATE alone and clean
separation between CREATE and ADMIN.

*Current implementation*
CREATE - CreateTable
OWNER+CREATE *or* ADMIN - AddColumn, DeleteColumn, DeleteTable, ModifyColumn,
ModifyTable, DisableTable, EnableTable

*Proposed implementation*
CREATE - CreateTable, AddColumn, DeleteColumn, DeleteTable, ModifyColumn,
ModifyTable, DisableTable, EnableTable

Remove the concept of table owner
-

Key: HBASE-6188
URL: https://issues.apache.org/jira/browse/HBASE-6188
Project: HBase
Issue Type: Sub-task
Components: security
Reporter: Andrew Purtell
Assignee: Laxman
Labels: security

[jira] [Updated] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-09 Thread Laxman (JIRA)


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

Laxman updated HBASE-6092:
--

Description: Currently, flush, split and compaction are not checked for 
authorization in AccessController. With the current implementation any 
unauthorized client can trigger these operations on a table.  (was: Currently, 
some operations like flush and split are not checked for authorization in 
AccessController. With the current implementation any unauthorized client can 
trigger these operations on a table.)
Summary: Authorize flush, split, compact operations in AccessController 
 (was: Authorize flush, split operations in AccessController)

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security

 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Commented] (HBASE-6092) Authorize flush, split, compact operations in AccessController

2012-06-09 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292441#comment-13292441
 ] 

Laxman commented on HBASE-6092:
---

Following is the approach I'm planning to proceed with.

1) split, compact and flush - authorize in AccessController using existing 
hooks.
2) pre/postSplit, pre/postCompact, pre/postFlush - signature in RegionObserver 
interface should be inline with other methods. [add missing throws clause]
3) if this operation is user triggered, authorization should be done with 
request user. otw, with system principal. [i guess this is implicitly taken 
care in AccessController.getActiveUser()]

please validate.

 Authorize flush, split, compact operations in AccessController
 --

 Key: HBASE-6092
 URL: https://issues.apache.org/jira/browse/HBASE-6092
 Project: HBase
  Issue Type: Sub-task
  Components: security
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security

 Currently, flush, split and compaction are not checked for authorization in 
 AccessController. With the current implementation any unauthorized client can 
 trigger these operations on a table.

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

[jira] [Commented] (HBASE-6096) AccessController v2

2012-06-09 Thread Laxman (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292442#comment-13292442
 ] 

Laxman commented on HBASE-6096:
---

Thanks for your inputs Andy and Matt.
I considered these points. please check the approach HBASE-6092.

 AccessController v2
 ---

 Key: HBASE-6096
 URL: https://issues.apache.org/jira/browse/HBASE-6096
 Project: HBase
  Issue Type: Umbrella
  Components: security
Affects Versions: 0.96.0, 0.94.1
Reporter: Andrew Purtell
 Attachments: Security-ACL Matrix.pdf


 Umbrella issue for iteration on the initial AccessController drop.

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

[jira] [Assigned] (HBASE-6192) Document ACL matrix in the book

2012-06-09 Thread Laxman (JIRA)


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

Laxman reassigned HBASE-6192:
-

Assignee: Laxman

 Document ACL matrix in the book
 ---

 Key: HBASE-6192
 URL: https://issues.apache.org/jira/browse/HBASE-6192
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.96.0
Reporter: Enis Soztutar
Assignee: Laxman

 We have an excellent matrix at 
 https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf
  for ACL. Once the changes are done, we can adapt that and put it in the 
 book, also add some more documentation about the new authorization features. 

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

[jira] [Updated] (HBASE-5372) Table mutation operations should check table level rights, not global rights

2012-06-08 Thread Laxman (JIRA)


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

Laxman updated HBASE-5372:
--

 Tags: Huawei
Fix Version/s: 0.94.1
   0.96.0
   Labels: security  (was: )
Affects Version/s: 0.94.1
   0.96.0
   0.94.0
   Status: Patch Available  (was: Open)

Corrected ACL as per the matrix.
https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf

Please review the patch.

 Table mutation operations should check table level rights, not global rights 
 -

 Key: HBASE-5372
 URL: https://issues.apache.org/jira/browse/HBASE-5372
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1


 getUserPermissions(tableName)/grant/revoke and drop/modify table operations 
 should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN 
 rights. The reasoning is that if a user is able to admin or read from a 
 table, she should be able to read the table's permissions. We can choose 
 whether we want only READ or ADMIN permissions for getUserPermission(). Since 
 we check for global permissions first for table permissions, configuring 
 table access using global permissions will continue to work. 

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

[jira] [Updated] (HBASE-5372) Table mutation operations should check table level rights, not global rights

2012-06-08 Thread Laxman (JIRA)


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

Laxman updated HBASE-5372:
--

Status: Open  (was: Patch Available)

 Table mutation operations should check table level rights, not global rights 
 -

 Key: HBASE-5372
 URL: https://issues.apache.org/jira/browse/HBASE-5372
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1


 getUserPermissions(tableName)/grant/revoke and drop/modify table operations 
 should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN 
 rights. The reasoning is that if a user is able to admin or read from a 
 table, she should be able to read the table's permissions. We can choose 
 whether we want only READ or ADMIN permissions for getUserPermission(). Since 
 we check for global permissions first for table permissions, configuring 
 table access using global permissions will continue to work. 

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

[jira] [Updated] (HBASE-5372) Table mutation operations should check table level rights, not global rights

2012-06-08 Thread Laxman (JIRA)


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

Laxman updated HBASE-5372:
--

Attachment: HBASE-5372.patch

 Table mutation operations should check table level rights, not global rights 
 -

 Key: HBASE-5372
 URL: https://issues.apache.org/jira/browse/HBASE-5372
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Enis Soztutar
Assignee: Laxman
  Labels: security
 Fix For: 0.96.0, 0.94.1

 Attachments: HBASE-5372.patch


 getUserPermissions(tableName)/grant/revoke and drop/modify table operations 
 should not check for global CREATE/ADMIN rights, but table CREATE/ADMIN 
 rights. The reasoning is that if a user is able to admin or read from a 
 table, she should be able to read the table's permissions. We can choose 
 whether we want only READ or ADMIN permissions for getUserPermission(). Since 
 we check for global permissions first for table permissions, configuring 
 table access using global permissions will continue to work. 

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

1 2 >

1 - 100 of 145 matches

Mail list logo