Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: marketing@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of kxepal@gmail.com designates
 74.125.82.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKZBVX3_AU7oDg-++8EF+FOcXYYBG8iuzpYczJWYtMPxakMkiw@mail.gmail.com>
References: <A4085263-94EA-4FB1-8AE5-AD8300E43126@thehoodiefirm.com>
	<CADA9kr_DOramzbuGxqZywNonqO0T9Y9-QZOijEFQ8B5mWpEk_A@mail.gmail.com>
	<CAKZBVX3_AU7oDg-++8EF+FOcXYYBG8iuzpYczJWYtMPxakMkiw@mail.gmail.com>
Date: Tue, 13 Jan 2015 08:36:19 +0400
Message-ID: 
 <CAHdjipJH4GgEGh-8SmPMxVd6fcLU84=uj2hBwpewLXsDhuD_pw@mail.gmail.com>
Subject: Re: [NEWS] Your links for the CouchDB Weekly News
From: Alexander Shorin <kxepal@gmail.com>
To: "marketing@couchdb.apache.org" <marketing@couchdb.apache.org>
Content-Type: text/plain; charset=UTF-8

On Tue, Jan 13, 2015 at 7:11 AM, Akshat Jiwan Sharma
<akshatjiwan@gmail.com> wrote:
> http://www.staticshin.com/programming/what-does-_security-secure-in-couchdb/

> 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:
http://docs.couchdb.org/en/latest/couchapp/ddocs.html#update-functions


--
,,,^..^,,,