On Fri, Nov 11, 2011 at 5:41 AM, Jens Alfke <jens@couchbase.com> wrote:
>
> On Nov 10, 2011, at 2:02 PM, Adam Kocoloski wrote:
>
>> Heh.  No, they're still stored out in the open for anyone to see.  Only the server admin passwords are stored in the .ini file.  Did you try creating a normal user?  As far as I know that documentation is still accurate.
>
> Aha, I’ve only got a single admin account on my server

Hi, Jens. Famous last words. :)

Having just an admin (actually, Admin Party) is the traditional (or at
least, historical) operating mode of CouchDB. (The test suite
"requires Admin Party" for historical reasons: most of it was written
when that was the only mode CouchDB had.)

> I can create a normal user by just doing a PUT to _users, but can I create an admin account that way too? Or do I have to modify the config file to do that?

Admins are managed completely differently from user accounts. You
actually do not need a _users document to make admin requests. All you
need is an entry in the "admins" config section. (I personally avoid
mentioning the .ini file. It is an implementation detail to the
/_config web API.)

That is sufficient to query couch with the _admin role. If you GET
/_session, you see this:

{ ok: true,
  userCtx:
   { name: '<whatever>',
     roles: [ '_admin'] },
  info:
   { authentication_db: '_users',
     authentication_handlers: [ 'oauth', 'cookie', 'default' ],
     authenticated: 'default' } }

You might ask: why not just have normal user accounts with "_admin" in
the roles. I once asked Chris that question, and he said just in case
something was deeply broken, you can always log in as the admin. What
a great example of evolutionary homology! (Homology is bat wings and
bird wings; fish tails and whale tails). Any Unix sysadmin will tell
you to keep a plain root user in /etc/password, for when your
NIS/LDAP/Kerberos fails.

Problem1: You can't grant additional roles to that user. You can't
give them a couch.app.profile.
Solution 1: Couch (actually this is 100% implemented in Futon if I
recall) creates a corresponding document in _users, to store normal
user stuff

Problem 2: What if the password and salt get out of sync with that in
the config? (Similarly, what if somebody tries to crack your admin
password?)
Solution 2: The document for the admin user omits the password_sha and
salt fields. They cannot go out of sync with the config, and they
cannot be seen by unprivileged users.

Side note: Just like Unix and Windows and everything else, we should
avoid using the admin account whenever possible. You might make an
operator error in Futon (e.g. click "delete database" instead of
"compact database"); and you are also vulnerable to XSS attacks. If
somebody can get javascript into a couchapp you use, they can query
that couch with your _admin cookie.

P.S. Speaking of homologies, it is time CouchDB adopted something like
password shadowing. I wish _users was generally inaccessible to
unprivileged users. You can do this today in the _security object, and
it works just fine; but users can't create or update their accounts.
The Ocasta Facebook plugin, and the BrowserID plugin complement this
with account autovivification. My inbox database patch could help too,
but it's still an incomplete solution. The point is, Couch, just like
Unix, can only go so far with a the comprehensive accounts database
flapping in the breeze.

-- 
Iris Couch