CouchDB/Iris Couch - noob security question

2
votes

I've been playing with Iris Couch using Futon, curl and reading the CouchDB security Wiki page and I'm a little confused about readers, admins & server admins.

Am I correct in saying that the "Create Server Admin" pop-up in Futon isn't actually creating a server admin, (the wiki mentions this is only done by editing a local.ini file)?

What you're really doing is creating documents in the _users database - giving users a username & password to authenticate with, after which their name or role is compared to any names/roles defined against a database security object?

Also, I noticed that the "require_valid_user" is set to false by default, so assuming Iris Couch has a server admin, does this mean that although users have to provide their username/password to authenticate - they're validated as anonymous, so no comparison is made against any database-defined security?

If I want to restrict a user to a specific database, do I need the "require_valid_user" setting to be set to true?

Cheers

2
couchdb
OK - thanks to Jason I realised I was missing a crucial bit of info - creating server admins creates a reference for that user in the "admin" section of your configuration. This basically means that the user can do what they like(!) regardless of the _security database as in my case. Once I removed my test2 user reference from that section, they no longer had any access to the db - as expected. – Neil

2 Answers

4
votes

When you use the "Create server admin" popup form, that is the same as editing the .ini files. (Internally, Futon will query the a /_config URL which is an HTTP API to edit the .ini files.)

The _users database is the authoritative location for all user acounts, their passwords, and their roles. When a user queries CouchDB with a password (or with a session cookie), that name and role will be used to grant or deny their query. The decision of whether to allow or disallow their query is made by checking the _security object in the database first. They must be in the "readers" section: either their name is in the "names" list, or their role must be in the "roles" list.

I recommend that you avoid the require_valid_user option. It is for very specialized situations.

3
votes

You can have database-specific users and roles. You need to modify the _security "document" for a given database. It's also documented here on the wiki.