couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Javier Candeira (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2390) Fauxton config, admin sections considered dangerous in 2.0
Date Mon, 17 Nov 2014 22:10:34 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215278#comment-14215278
] 

Javier Candeira commented on COUCHDB-2390:
------------------------------------------

> Since we're going to drop Admin Party, we still have to provide some console tool to
setup first admin

I'm working on a couchpasswd tool to edit hashed passwords into the config file as part of

https://issues.apache.org/jira/browse/COUCHDB-2367

> As backward compatible feature, it could read admins from ini, but never write them back
with hash.

My opinion is that anyone setting up a cluster should copy the same config file (or [admins]
section) to all nodes. Anyone half serious should be using some kind of puppet/chef/ansible
tool for that anyway, and any learning hobbyist can very well go in and edit the file themselves
by hand. They need to set the same erlang cookie anyway, so why not the [admins] section too.

The reason is that I see a source of conflicts in cluster nodes reading admins from ini, but
not writing them back. 

1. Admin Arms sets hashed admin passwords for all admins in the nodes. They are the same for
every node/admin pair.
2. Nodes read hashed admin passwords into _authdb.
3. Admin Boo changes their own admin passwords in _authdb. 
4. Admin Chris is new, and they modify the config file only in one of the nodes, for themselves
and for admin Dan (Dan asked Chris to take Dan's hashed password from another setup). Does
this action change both their passwords in _authdb?. Should _authdb replication check that
the config was the same in all three nodes? 
5. Whatever the case, admin Chris finally changes the config in all three nodes.
6. Admin Dan then attempts to change their own admin password in authdb. Should he succeed?
What password should they use, the one Arms set on 1, or the one Chris set on 5?
7. The cluster is restored from backups, and as part of the restore, admin Ems uses the old
config, with the old [admins] section in the config, except that she first puts in a new password
for herself, and puts it in the local.ini of all four nodes before bringing the nodes up.


What is the expected behaviour now? Does Em have admin access, because the new config overrrode
the authdb setup on startup? Or does the restored-from-backup authdb override the [admins]
section in the config? Do Boo and Dan still have access with their passwords they changed
in authdb? Does Chris use their old password that Arms set in 1, or the new one they set themselves
in 4-5? 

I guess the question is, in the presence of authdb, is the [admins] section in a config file
just another way for inputting an admin's passed hashword into the database? Does the cluster
replicate the new admin passwds to all nodes? Going forward, what good is a config file that's
out of sync then?


> Fauxton config, admin sections considered dangerous in 2.0
> ----------------------------------------------------------
>
>                 Key: COUCHDB-2390
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2390
>             Project: CouchDB
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: BigCouch, Fauxton
>            Reporter: Joan Touzet
>            Priority: Blocker
>
> In Fauxton today, there is are 2 sections to edit config-file settings and to create
new admins. Neither of these sections will work as intended in a clustered setup.
> Any Fauxton session will necessarily be speaking to a single machine. The config APIs
and admin user info as exposed will only add that information to a single node's .ini file.
> We should hide these features in Fauxton for now (short-term fix) and correct the config
/admin creation APIs to work correctly in a clustered setup (medium-term fix).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message