[
https://issues.apache.org/jira/browse/ZOOKEEPER-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033220#comment-16033220
]
Michael Han commented on ZOOKEEPER-2779:
----------------------------------------
Latest patch looks good to me.
[~fpj] I was thinking about having a parameterized ACL as a config option
similar as you mentioned, which has the benefit of combined flexibility and
security (offline configuration). I think we should add that as well. The
question is should we keep the skipACL check option proposed in this patch, or
dump it in favor of the (overloaded) parameterized ACL config option? I am
leaning towards keep the skip ACL check option in this patch, which sounds like
a good option for user in use cases where they either don't care about
security, or security is enforced by other mechanisms, without thinking too
much about the semantic of the parameterized ACL, which might make ZK easier to
use. We can add the parameterized ACL config option for the config node in a
separate JIRA.
> Add option to not set ACL for reconfig node
> -------------------------------------------
>
> Key: ZOOKEEPER-2779
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2779
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.5.3
> Reporter: Jordan Zimmerman
> Assignee: Jordan Zimmerman
> Fix For: 3.5.4, 3.6.0
>
>
> ZOOKEEPER-2014 changed the behavior of the /zookeeper/config node by setting
> the ACL to {{ZooDefs.Ids.READ_ACL_UNSAFE}}. This change makes it very
> cumbersome to use the reconfig APIs. It also, perversely, makes security
> worse as the entire ZooKeeper instance must be opened to "super" user while
> enabled reconfig (per {{ReconfigExceptionTest.java}}). Provide a mechanism
> for savvy users to disable this ACL so that an application-specific custom
> ACL can be set.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
