[GitHub] jaydoane commented on issue #1803: Sync admin passwords at cluster setup finish

[GitBox <gi...@apache.org>]

jaydoane commented on issue #1803: Sync admin passwords at cluster setup finish
URL: https://github.com/apache/couchdb/pull/1803#issuecomment-448774242
 
 
   @wohali writes:
   > do we still want to merge this, even though it only addresses one specific scenario discussed in #1781?
   
   I think I would put it somewhat differently. To summarize, (and ignoring single-node config), there are basically two scenarios in which one can currently use the cluster setup code: both ways start with an "enable_cluster" request to the coordinating node, and both end with a "finish_cluster" request to the coordinating node. The scenarios only differ in the following ways:
   1. In the "direct" scenario, (which appears to have been the first implemented), the client makes an "enable_cluster" request directly to each additional non-coordinating node in the cluster, followed by an "add_node" request to the coordinating node for the node being added.
   2. In the "remote" scenario, the client instead makes a "remote enable_cluster" request and a subsequent "add_node" request to the coordinating node for the node being added.
   
   The key difference between the two is that in scenario 2, instead of directly making a request to the new nodes, the client makes requests to the coordinator, and then the coordinator makes requests to the new nodes. The main benefit of this approach is that the coordinator sends the admin `password_hash` to the new nodes rather than the password itself, so that the hashes are the same on all nodes.
   
   However, when this patch runs during the "finish_cluster" request, it *also* syncs the password hash from the coordinator to the other nodes in the cluster, and so scenario 1 also enjoys the benefits of synced admin password hashes (and is also redundant to how scenario 2 does it). Additionally, it creates a cluster-wide password salt (if one has not already been pre-defined in a config file) and syncs that, so that any subsequent admin user that gets added to the cluster will also have the same hashed password.
   
   It's that last bit that I *thought* was originally being requested, but it now sounds like there is a question about whether it's a good idea to salt all admin passwords with the same salt. If we decide that doing so is ok, then I think merging this patch will improve admin password administration overall. Otherwise, I'm fine to drop it and close this PR. I'm also happy to remove the "Fixes #1781" part, although I'm not exactly sure how, other than not clarifying the documentation, this doesn't fix inconsistent admin password hashes during cluster setup.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services