[
https://issues.apache.org/jira/browse/ZOOKEEPER-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384994#comment-15384994
]
Michael Han commented on ZOOKEEPER-2014:
----------------------------------------
Had an offline discussion with [~phunt], [~fpj] yesterday regarding this issue,
the conversation is captured as following points (with some of my thoughts as
well):
* We can't fix security issue unless we enforce authentication and
authorization. Just by moving client APIs around is not enough because at
protocol level the server still open to reconfiguration and someone can exploit
this easily (by writing their own ZK client instead of using ZooKeeper client
for example.).
* That said though, the ZooKeeper::reconfig API should be moved out of
ZooKeeper class (for Java client) anyway, because it's more about an admin
feature rather than a client API. Moving reconfig out of ZooKeeper will also
remove constraints we possibly put on normal ZooKeeper clients (such as having
to use zookeeper.DigestAuthenticationProvider.superDigest), which is a bonus.
Due to API backward compatibility concerns, this refactoring should happen
before we move to beta.
* We'd like to introduce a new configuration option in zoo.cfg to turn off
reconfig feature by default. ZK users who needs use this feature need turn it
on explicitly. Because dynamic reconfig feature brings something new (e.g.
cfg.dynamic file), have this feature off is good for 'the principal of least
surprise'. Having the feature off by default will also buy us sometime to
fortify and stabilize the feature without having it being a blocker issue.
The action items / plans I am thinking in the time frame of 3.5.3:
* Move ZooKeeper::reconfig into ServerAdminClient. ZooKeeper::getConfig will
remain as is.
* To run ServerAdminClient with reconfig command, clients need to use
zookeeper.DigestAuthenticationProvider.superDigest and on server side we check
superuser. This is basically what the current patch does today.
* Introduce a new configuration option to turn on / off reconfig code path.
Are these good enough for now to address all security concerns or we still miss
something?
Comments?
CC [~shralex], [~rgs]
> Only admin should be allowed to reconfig a cluster
> --------------------------------------------------
>
> Key: ZOOKEEPER-2014
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2014
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.5.0
> Reporter: Raul Gutierrez Segales
> Assignee: Michael Han
> Priority: Blocker
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2014.patch
>
>
> ZOOKEEPER-107 introduces reconfiguration support via the reconfig() call. We
> should, at the very least, ensure that only the Admin can reconfigure a
> cluster. Perhaps restricting access to /zookeeper/config as well, though this
> is debatable. Surely one could ensure Admin only access via an ACL, but that
> would leave everyone who doesn't use ACLs unprotected. We could also force a
> default ACL to make it a bit more consistent (maybe).
> Finally, making reconfig() only available to Admins means they have to run
> with zookeeper.DigestAuthenticationProvider.superDigest (which I am not sure
> if everyone does, or how would it work with other authentication providers).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
