What was the logic of requiring ZK users to connect via super user for new databases in order to allow the reconfig() APIs to work? As it stands, trying to use the reconfig APIs with 3.5.3 is extremely cumbersome. In the name of security the feature has gotten hobbled. Why can't this all be accomplished via zoo.cfg?
Prior to 3.5.3: users could use reconfig() at will. If they wanted better security they could set ACLs on /zookeeper/config. Since 3.5.3: reconfig() is limited to "super" user. Perversely, this reduces security as "super" user is utterly insecure. Requiring new databases to be post-applied via super user creates a security hole. For the time that the new ACLs for /zookeeper/config are to be changed the ZooKeeper instance will be in "super" user mode. Additionally, having to do all this is terribly cumbersome. Lastly, the docs only make passing mention of this. I think users will be very surprised by this - especially as the docs refer users to ReconfigExceptionTest.java which isn't part of the client distribution. Am I missing something here? -Jordan
