Thank you for proofreading this Alexander :) I added all of your comments as notes to the original. Check it out
http://www.staticshin.com/programming/what-does-_security-secure-in-couchdb/ On Tue, Jan 13, 2015 at 10:06 AM, Alexander Shorin <[email protected]> wrote: > On Tue, Jan 13, 2015 at 7:11 AM, Akshat Jiwan Sharma > <[email protected]> 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 > > > -- > ,,,^..^,,, >
