[
https://issues.apache.org/jira/browse/ZOOKEEPER-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033072#comment-16033072
]
Jordan Zimmerman edited comment on ZOOKEEPER-2779 at 6/1/17 2:32 PM:
---------------------------------------------------------------------
[~fpj] I'm OK with either. But, this works best for us - i.e. restoring the old
behavior (save the reasonable reconfigEnabled setting in zoo.cfg). The hack -
from my view - is requiring that your entire ZooKeeper ensemble be open to a
root-style single password (that is discoverable via a simple {{ps ax | grep
java}} in order to use the reconfig() APIs.
was (Author: randgalt):
[~fpj] I'm OK with either. But, this works best for us - essentially restoring
the old behavior. The hack - from my view - is requiring that your entire
ZooKeeper ensemble be open to a root-style single password (that is
discoverable via a simple {{ps ax | grep java}} in order to use the reconfig()
APIs.
> 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)
