All this s/homology/analogy/ How humiliating!
On Fri, Nov 11, 2011 at 8:00 AM, Jason Smith <[email protected]> wrote: > On Fri, Nov 11, 2011 at 5:41 AM, Jens Alfke <[email protected]> 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 > -- Iris Couch
