Yes, this is a concern for me as well.
1) mixing the client api and the admin api is not great. It would be better to have them separate. We should fix this asap.
2) this (controlling access to reconfig) is a big issue from a security perspective IMO.
A few comments on the comments so far:
ensure that only the Admin can reconfigure a cluster
sounds sensible to me
Perhaps restricting access to /zookeeper/config as well
in the past we've (ben in particular) tried to limit the amount of information we provide to the client/session. For example we don't tell them which server they are connected to. I see this in the same vein.
one could ensure Admin only access via an ACL, but that would leave everyone who doesn't use ACLs unprotected.
well, you're already unprotected in this situation so I don't really see it as a sticking point.
clients may need read access for example in order to run the new client-side load balancing functionality
perhaps this argues for pushing this to the the server? encapsulate the information on the service I mean and expose as a specific api.
Actually perhaps we should open a JIRA to hide the client-side rebalancing from clients (not for 3.5.0).
yes, that's what I was trying to get at in the previous item in this comment. Although I think we'd need to fix this now - while we can still change the apis w/o worrying about b/w compat (we can change new apis during the alpha period w/o worrying about back compat)
should this be similar to how updating the quota znode works ? or do you think changing configuration is different ?
if quotas are "admin" functions we probably need to fix those as well - lock them down to just admin level authz I mean.