[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068043#comment-16068043
]
Shibin Zhang commented on HBASE-15577:
--
Is this patch available?
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577-02.patch, HBASE-15577-03.patch,
> HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
> manual steps to verify the patch
> *1.set this property in the hbase-site.xml*
> {quote}
>hbase.security.authentication(simple)
>hbase.zookeeper.acl (digest:admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc=:cdrwa)
>hbase.zookeeper.auth(digest:admin)
> {quote}
> the digest can generate by the
> DigestAuthenticationProvider.generateDigest("admin")
> *2.start the cluster*
> *3.verify the zk's node*
> {quote}
>(1)getAcl /hbase, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
>'world,'anyone: r
>(2)getAcl /hbase/table-lock, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
> {quote}
> if the node is below, all the client can read the node, but only the
> server(Regionserver & Master which has the auth info) can modify it
> {quote}
> /hbase
> /hbase/meta-region-server
> /hbase/master
> /hbase/hbaseid
> /hbase/rs
> /hbase/table
> /hbase/table/$tableName
> {quote}
> otherwise, only the server can read and modify the node, the Client can't see
> them
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15234405#comment-15234405
]
chenxu commented on HBASE-15577:
Hi,Heng Chen
if the client needs to modify these node, and you trust it, i think you can
grant auth to it manually.
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577-02.patch, HBASE-15577-03.patch,
> HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
> manual steps to verify the patch
> *1.set this property in the hbase-site.xml*
> {quote}
>hbase.security.authentication(simple)
>hbase.zookeeper.acl (digest:admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc=:cdrwa)
>hbase.zookeeper.auth(digest:admin)
> {quote}
> the digest can generate by the
> DigestAuthenticationProvider.generateDigest("admin")
> *2.start the cluster*
> *3.verify the zk's node*
> {quote}
>(1)getAcl /hbase, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
>'world,'anyone: r
>(2)getAcl /hbase/table-lock, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
> {quote}
> if the node is below, all the client can read the node, but only the
> server(Regionserver & Master which has the auth info) can modify it
> {quote}
> /hbase
> /hbase/meta-region-server
> /hbase/master
> /hbase/hbaseid
> /hbase/rs
> /hbase/table
> /hbase/table/$tableName
> {quote}
> otherwise, only the server can read and modify the node, the Client can't see
> them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15233806#comment-15233806
]
Heng Chen commented on HBASE-15577:
---
{quote}
if the node is below, all the client can read the node, but only the
server(Regionserver & Master which has the auth info) can modify it
/hbase
/hbase/meta-region-server
/hbase/master
/hbase/hbaseid
/hbase/rs
/hbase/table
/hbase/table/$tableName
otherwise, only the server can read and modify the node, the Client can't see
them
{quote}
There are some nodes we need to modify and read in client side, for example,
/hbase/replication, /hbase/swithes. How to deal with this nodes?
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577-02.patch, HBASE-15577-03.patch,
> HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
> manual steps to verify the patch
> *1.set this property in the hbase-site.xml*
> {quote}
>hbase.security.authentication(simple)
>hbase.zookeeper.acl (digest:admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc=:cdrwa)
>hbase.zookeeper.auth(digest:admin)
> {quote}
> the digest can generate by the
> DigestAuthenticationProvider.generateDigest("admin")
> *2.start the cluster*
> *3.verify the zk's node*
> {quote}
>(1)getAcl /hbase, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
>'world,'anyone: r
>(2)getAcl /hbase/table-lock, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
> {quote}
> if the node is below, all the client can read the node, but only the
> server(Regionserver & Master which has the auth info) can modify it
> {quote}
> /hbase
> /hbase/meta-region-server
> /hbase/master
> /hbase/hbaseid
> /hbase/rs
> /hbase/table
> /hbase/table/$tableName
> {quote}
> otherwise, only the server can read and modify the node, the Client can't see
> them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231607#comment-15231607
]
Yu Li commented on HBASE-15577:
---
The new {{TestSimpleZKACL}} case looks good.
Please use LOG.warn instead of printStackTrace in the below part:
{noformat}
+ } catch (IOException e) {
+e.printStackTrace();
+return Ids.OPEN_ACL_UNSAFE;
+ }
{noformat}
All other parts lgtm. Thanks.
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577-02.patch, HBASE-15577-03.patch,
> HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
> manual steps to verify the patch
> *1.set this property in the hbase-site.xml*
> {quote}
>hbase.security.authentication(simple)
>hbase.zookeeper.acl (digest:admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc=:cdrwa)
>hbase.zookeeper.auth(digest:admin)
> {quote}
> the digest can generate by the
> DigestAuthenticationProvider.generateDigest("admin")
> *2.start the cluster*
> *3.verify the zk's node*
> {quote}
>(1)getAcl /hbase, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
>'world,'anyone: r
>(2)getAcl /hbase/table-lock, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
> {quote}
> if the node is below, all the client can read the node, but only the
> server(Regionserver & Master which has the auth info) can modify it
> {quote}
> /hbase
> /hbase/meta-region-server
> /hbase/master
> /hbase/hbaseid
> /hbase/rs
> /hbase/table
> /hbase/table/$tableName
> {quote}
> otherwise, only the server can read and modify the node, the Client can't see
> them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231551#comment-15231551
]
chenxu commented on HBASE-15577:
it's my mistake, the UT case has uploaded, very glad if you have some advise on
it
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577-02.patch, HBASE-15577-03.patch,
> HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
> manual steps to verify the patch
> *1.set this property in the hbase-site.xml*
> {quote}
>hbase.security.authentication(simple)
>hbase.zookeeper.acl (digest:admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc=:cdrwa)
>hbase.zookeeper.auth(digest:admin)
> {quote}
> the digest can generate by the
> DigestAuthenticationProvider.generateDigest("admin")
> *2.start the cluster*
> *3.verify the zk's node*
> {quote}
>(1)getAcl /hbase, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
>'world,'anyone: r
>(2)getAcl /hbase/table-lock, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
> {quote}
> if the node is below, all the client can read the node, but only the
> server(Regionserver & Master which has the auth info) can modify it
> {quote}
> /hbase
> /hbase/meta-region-server
> /hbase/master
> /hbase/hbaseid
> /hbase/rs
> /hbase/table
> /hbase/table/$tableName
> {quote}
> otherwise, only the server can read and modify the node, the Client can't see
> them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229660#comment-15229660
]
Yu Li commented on HBASE-15577:
---
Oops, seems some misunderstanding here on UT case... I meant checking the
design of TestZookeeperACL in hbase-server and add another case to cover the
manual steps [~javaman_chen]
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577-02.patch, HBASE-15577-03.patch,
> HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
> manual steps to verify the patch
> *1.set this property in the hbase-site.xml*
> {quote}
>hbase.security.authentication(simple)
>hbase.zookeeper.acl (digest:admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc=:cdrwa)
>hbase.zookeeper.auth(digest:admin)
> {quote}
> the digest can generate by the
> DigestAuthenticationProvider.generateDigest("admin")
> *2.start the cluster*
> *3.verify the zk's node*
> {quote}
>(1)getAcl /hbase, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
>'world,'anyone: r
>(2)getAcl /hbase/table-lock, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
> {quote}
> if the node is below, all the client can read the node, but only the
> server(Regionserver & Master which has the auth info) can modify it
> {quote}
> /hbase
> /hbase/meta-region-server
> /hbase/master
> /hbase/hbaseid
> /hbase/rs
> /hbase/table
> /hbase/table/$tableName
> {quote}
> otherwise, only the server can read and modify the node, the Client can't see
> them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15229637#comment-15229637
]
chenxu commented on HBASE-15577:
yeah, i think you are right, the identifier check is remove
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577-02.patch, HBASE-15577-03.patch,
> HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
> manual steps to verify the patch
> *1.set this property in the hbase-site.xml*
> {quote}
>hbase.security.authentication(simple)
>hbase.zookeeper.acl (digest:admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc=:cdrwa)
>hbase.zookeeper.auth(digest:admin)
> {quote}
> the digest can generate by the
> DigestAuthenticationProvider.generateDigest("admin")
> *2.start the cluster*
> *3.verify the zk's node*
> {quote}
>(1)getAcl /hbase, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
>'world,'anyone: r
>(2)getAcl /hbase/table-lock, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
> {quote}
> if the node is below, all the client can read the node, but only the
> server(Regionserver & Master which has the auth info) can modify it
> {quote}
> /hbase
> /hbase/meta-region-server
> /hbase/master
> /hbase/hbaseid
> /hbase/rs
> /hbase/table
> /hbase/table/$tableName
> {quote}
> otherwise, only the server can read and modify the node, the Client can't see
> them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228223#comment-15228223
]
Yu Li commented on HBASE-15577:
---
bq. the reason why of the HMaster.MASTER & HRegionServer.REGIONSERVER not used
is because of hbase-client has no dependency on the hbase-server
Ok, then I suggest to move the constants into HConstants, and use them for all,
if necessary.
bq. the client just need some auth to read the ZK's node, but can't modify them.
The auth config is read from the configuration file, right? IMO it's better to
control the access through configuration (wrong auth won't be able to access).
OTOH, since ZookeeperWatcher is {{IA.Private}}, if no special design for UT
case, I think we could even remove the identifier check.
W.r.t unit test, it would be great if you could refer to {{TestZooKeeperACL}}
to add a case for the sanity test steps in description. Thanks.
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577-02.patch, HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
> manual steps to verify the patch
> *1.set this property in the hbase-site.xml*
> {quote}
>hbase.security.authentication(simple)
>hbase.zookeeper.acl (digest:admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc=:cdrwa)
>hbase.zookeeper.auth(digest:admin)
> {quote}
> the digest can generate by the
> DigestAuthenticationProvider.generateDigest("admin")
> *2.start the cluster*
> *3.verify the zk's node*
> {quote}
>(1)getAcl /hbase, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
>'world,'anyone: r
>(2)getAcl /hbase/table-lock, result is:
>'digest,'admin:0DPiKuNIrrVmD8IUCuw1hQxNqZc= : cdrwa
> {quote}
> if the node is below, all the client can read the node, but only the
> server(Regionserver & Master which has the auth info) can modify it
> {quote}
> /hbase
> /hbase/meta-region-server
> /hbase/master
> /hbase/hbaseid
> /hbase/rs
> /hbase/table
> /hbase/table/$tableName
> {quote}
> otherwise, only the server can read and modify the node, the Client can't see
> them
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227927#comment-15227927
]
Hadoop QA commented on HBASE-15577:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 38s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 29s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 6s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 41s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 8s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 28s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 28s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 6s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 6s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 21s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 38s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 42s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 44s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 55s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 54s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 66m 4s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12797256/HBASE-15577-02.patch |
| JIRA Issue
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[ https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227855#comment-15227855 ] chenxu commented on HBASE-15577: hi, Yu Li it's a good advice to return Ids.OPEN_ACL_UNSAFE in the catch block. the reason why of the HMaster.MASTER & HRegionServer.REGIONSERVER not used is because of hbase-client has no dependency on the hbase-server, ZooKeeperWatcher.java is in the hbase-client module and HMaster.java/HRegionServer.java is in the hbase-server module. besides this, the client just need some auth to read the ZK's node, but can't modify them. so only when the identifier is a Server(HMaster or RegionServer), the auth can assign to it. > there need be a mechanism to enable ZK's ACL check when the authentication > strategy is simple > - > > Key: HBASE-15577 > URL: https://issues.apache.org/jira/browse/HBASE-15577 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.1.3 >Reporter: chenxu >Assignee: chenxu > Attachments: HBASE-15577.patch, zk-set-acl.patch > > > if the hbase.security.authentication is set to simple, the ZKUtil.createACL > just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's > node. > we can refactoring this to enables the ACL's check function -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222886#comment-15222886
]
Yu Li commented on HBASE-15577:
---
I think this is a good way to supply some light-weight security. Some review
points:
In {{ZKUtil}}:
{noformat}
+ } catch (IOException e) {
+e.printStackTrace();
+ }
{noformat}
I think we should fall back to return {{Ids.OPEN_ACL_UNSAFE}} here.
In {{ZooKeeperWatcher}}:
{noformat}
+if("master".equals(identifier) || "regionserver".equals(identifier)){
{noformat}
Why only read auth for HMaster/RS? IMO we should also support client auth
right? If any special reason to limit the auth to master/rs, we should use
{{HMaster.MASTER}} and {{HRegionServer.REGIONSERVER}} instead of the hard-coded
strings.
Please also add some UT case for this feature. Thanks.
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: HBASE-15577.patch, zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222715#comment-15222715
]
Hadoop QA commented on HBASE-15577:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 39s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m 23s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 18s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 36s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 7s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 15s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
57s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 28s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 28s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 56s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 56s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
6s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 5 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 9s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 19s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 49s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 24s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 22s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 17s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 17s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 111m 25s {color}
| {co
[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221509#comment-15221509
]
Hadoop QA commented on HBASE-15577:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 7s {color}
| {color:red} HBASE-15577 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.2.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796512/zk-set-acl.patch |
| JIRA Issue | HBASE-15577 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1261/console |
| Powered by | Apache Yetus 0.2.0 http://yetus.apache.org |
This message was automatically generated.
> there need be a mechanism to enable ZK's ACL check when the authentication
> strategy is simple
> -
>
> Key: HBASE-15577
> URL: https://issues.apache.org/jira/browse/HBASE-15577
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 1.1.3
>Reporter: chenxu
>Assignee: chenxu
> Attachments: zk-set-acl.patch
>
>
> if the hbase.security.authentication is set to simple, the ZKUtil.createACL
> just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's
> node.
> we can refactoring this to enables the ACL's check function
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
