[
https://issues.apache.org/jira/browse/ZOOKEEPER-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027002#comment-16027002
]
Jordan Zimmerman commented on ZOOKEEPER-2779:
---------------------------------------------
In our use case, we have an automated ZooKeeper installation that runs without
human intervention. We need to be able to set proper ACLs on the reconfig nodes
and also use the reconfig() APIs. In the 3.5.3, that is impossible. Reconfig is
disabled unless you turn on super-user mode and fix the ACLs on
{{/zookeeper/config}}. In our use case (and I imagine a great many others), at
installation time there is zero risk - we know what we're doing. This is not
running on an untrusted network. Forcing users to jump through hoops to use
reconfig is strange - I still don't understand it.
> 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)
