couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Configuration Load Order
Date Wed, 17 Aug 2011 17:15:14 GMT
To be clear, is the suggestion that this script simply be a wrapper around updating the password
via CouchDB's HTTP API? Having gone back and forth on this thread for the past few days, I
think it makes sense to keep user info in CouchDB, and not in the ini files. If a user manages
to lock themselves out of the server, they can start it with --admin-party and disable the
auth system while they fix things up.

On 17 Aug 2011, at 17:09, Robert Newson wrote:

> It's also the sort of thing one would expect in a Debian postinst via Dialog.
> B.
> On 17 August 2011 17:04, Benoit Chesneau <> wrote:
>> On Wednesday, August 17, 2011, Jason Smith <> wrote:
>>> On Wed, Aug 17, 2011 at 10:22 PM, Robert Newson <>
>> wrote:
>>>> Jason,
>>>> The --set-password thing is to ensure there are no plaintext passwords
>>>> in the first place, which eliminates the oddness of couch rewriting a
>>>> plaintext pwd to a digested pwd (and putting the output in a different
>>>> file).
>>> Thanks for the clarification.
>>> If you can read a plaintext password from an .ini file, then you can
>>> hit the HTTP API as the admin and make changes to the couch. So that
>>> is privilege escalation.
>>> To answer Benoit's question, it is simpler to tell admins to use the
>>> HTTP API (or Futon) to create the admin account. The password is
>>> stored *somewhere* under the hood. IMHO it is less simple to add a
>>> command-line tool as a requirement (or worse, as an alternative
>>> option) to deploy Couch.
>>> --
>> it all depends if you admin via a console.
>> couchctl set-password username is a way easier than curl -XPUT
>> http://blah/_users -D... -H...  . at the end if you are a good admin you
>> will write this script. providing useful helpere don't break the kiss way
>> here.
>> benoƮt

View raw message