Understanding Admins name/role and Members name/role settings

[fangq]

I am building website for sharing public data using CouchDB as the backend. I want the data to be publicly accessible without logins (i.e. anonymously readable by default). But I want only designated CouchDB users (in addition to site admins) to be able to write to the databases.

So far, I was able to achieve this using the following settings

• I disabled default_security = admin_only so that everyone can read
• I added a validate_doc_update handler to raise an error if userCtx.name is not present - preventing anonymous users to write
• I removed _admin roles for both Admins and Members for each created database
• I created CouchDB users (not site admins) and assign those user names as Admin user name for each database, keeping the roles still empty (Members user name and roles are also empty).

I found that the above settings mostly do what I hoped (unless I overlooked) - anonymous users can browse, but not deleting/modifying data; couchdb users can upload/update/delete documents using their credentials. Only site admins can create new databases, modify design docs etc.

However, I found one problem - it appears that regardless if a couchdb user is assigned to a database as admin or not, any valid user can upload/update documents to such database.

I have two questions

1. does the above setting have any perceivable security risks?
2. is there a way I can limit the users who can commit changes (add, modify, delete) documents from a database to those I explicitly list under the admin? should this be explicitly implemented in the validate_doc_update handler?

here is a screenshot of the permission settings of one of my databases

PS: my 2nd question was solved - I modified my validate_doc_update handler and test the user name against secObj. it now prevents anyone who is not listed under secObj to post updates.

[rnewson]

what did you set default_security to?;

default.ini

; Default security object for databases if not explicitly set
; everyone - same as couchdb 1.0, everyone can read/write
; admin_only - only admins can read/write
; admin_local - sharded dbs on :5984 are read/write for everyone,
;               local dbs on :5986 are read/write for admins only
;default_security = admin_only

[fangq]

it was commented out - I assume it revert to "everyone"?

;default_security = admin_only

[fangq]

I have a follow up question regarding my above question 2.

I am using the following validate_doc_update handler to explicitly permit database-specific admins to update the document

function(newDoc, oldDoc, userCtx, secObj) {
    if('_admin' in userCtx.roles)
        return;
    if(!userCtx.name) {
        throw({'forbidden': 'auth first before update something'});
    }
    if(!secObj.admins.names.includes(userCtx.name)) {
        throw({'forbidden': 'user is not allowed'});
    }
}

this works generally well. However, I noticed that if I log in with a server-admin account, it rejects the update by throwing the "forbidden': 'user is not allowed'" error.

is _admin automatically attached to al server-admin accounts? if not, what exactly is _admin?

[janl]

server admins do get the _admin role automatically

[fangq]

@janl, after printing the userCtx.roles variable for a server-admin, I can see it has _admin. I found that the reason server-admin were rejected was because of an improper condition

I changed from

if('_admin' in userCtx.roles)
  return

to

if(userCtx.roles.indexOf('_admin') !== -1)
  return

it now works.

would you be able to comment on my 1st question above?

1. does the above setting have any perceivable security risks?

[rnewson]

it was commented out - I assume it revert to "everyone"?

nope. if not specified in the .ini file the default value is admin_only. The commented items in default.ini document the defaults when the value is not set.

[fangq]

I see - I remember when I tried to make my databases visible for anonymous users, I had to remove the _admin role from Admin and Users in the permission tab of each database. After that, anonymous users can read and write - I had to block them from writing using the validate_doc_update handler, see my code above.