couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Akshat Jiwan Sharma <>
Subject Re: [NEWS] Your links for the CouchDB Weekly News
Date Tue, 13 Jan 2015 05:09:23 GMT
Thank you for proofreading this Alexander :) I added all of your comments
as notes to the original. Check it out

On Tue, Jan 13, 2015 at 10:06 AM, Alexander Shorin <> wrote:

> On Tue, Jan 13, 2015 at 7:11 AM, Akshat Jiwan Sharma
> <> wrote:
> >
> > Every _security document consists of two mandatory fields called admins
> and members.
> They aren't mandatory at all, just the ones which CouchDB handles in
> special way and requires them to have special structure.
> > The name in an admin or a member property must be the name of the user
> stored in _users database.
> The "must" is too strong requirement. The name must be string, but it
> should point on some user name, which even may not be existed at all.
> However, this is a security leak in this case.
> > When couchdb authenticates a user from the _users database it can run
> checks against the _security document of each database to determine whether
> the authenticated user is an admin or a member.
> When user requests database or any it subresource, CouchDB check his
> context (userCtx - a user name and list of their roles) against
> database _security.
> > The roles property on the other hand is free form--- meaning you can
> supply any value in the roles array.
> Any string value. In 1.3.0 we'd dropped support of non-string roles.
> That was bad hack.
> > An admin is authorized to perform CRUD on _design and _security
> documents.
> And run any IO-related tasks on database they admins, like compaction,
> running temporary views and views indexes cleanup.
> > A member can only read or write normal documents--- all documents except
> _design and the _security documents.
> Members can read design documents, but no modify the. Same about _security
> one.
> > Once you add a _security to the database then the database can only be
> accessed by the person who is a part of the _security document. Any
> unauthorized person would be forbidden from accessing the database.
> Once you specify database members it becomes only accessible to those
> users or users with specified roles in additional to admin. Those who
> specified in admins grants a power to run IO operations upon database,
> manage _security and design documents.
> > The conclusion is pretty easy to draw. couchdb offers minimal read level
> security on the normal documents (that is all documents except the special
> _design and _security documents).
> Same is above. _security members controls global database read bit;
> _security admins controls exec bit for service operations and write
> bit for design docs and security.
> > You can add conditional checks on who creates, updates or deletes a
> document using document update functions.
> Correction: using validate document update functions. The update
> functions is a little bit different thing:
> --
> ,,,^..^,,,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message