couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Trauzzi (JIRA)" <>
Subject [jira] Commented: (COUCHDB-615) Role, ACL and Ownership Checks
Date Wed, 13 Jan 2010 01:08:54 GMT


Alexander Trauzzi commented on COUCHDB-615:

The first part of this note is an aside which could be separated out into another discussion
or issue if desired...

It's important not to conflate the functionality of reading the DB from an application point
of view (JSON request coming from a browser) and reading the DB as a function of infrastructure
(a scheduled replication).

I should note that I see the use in allowing replications to happen in the context of a user
per database, but *not per server*.  This allows for local copies of DB for higher availability,
but they are only populated with data the user can see.
Ultimately, replications and DBs will have to function in different contexts.  Control over
what replications a server performs is still a system-wide administrative task to be done
with absolute authority.

1. is running couchdb.
2. I make a user there.
3. I start to populate my CD collection and share information with others.\
4. I'm going on a plane and want my CD collection list with me.
5. I install CouchDB on my favorite OS via my favorite means.
6. As I am an administrator on my laptop, I elect to replicate
7. requires that I authenticate so that it can
filter my replication.

I think you can see how incredibly neat that ends up being...Of course then some people will
want ways to obfuscate the _design docs... But that's getting into the nitty gritties.

Replication should function with indifference towards the DBs, users and CouchApps being replicated
and have little to nothing to do with them.  It should function behind the scenes as part
of a broader, more general systems design.
That's why things like per-DB roles and users may be nessecary to prevent the server and the
databases from bleeding into each other.

To me, replication is not something my users should even have to know about.  You write one
app and if you need to scale out, you simply set up replication.


This issue that I have made here is over the permissions of authenticated users of the DB
and what data they can and cannot read:

Right now, there is no way to secure a request to http://mycouchdb/mydb/myprivatedata on CouchDB
without involving cumbersome workarounds.  I am loathe to think of the impact on the project
if this is not addressed.

> Role, ACL and Ownership Checks
> ------------------------------
>                 Key: COUCHDB-615
>                 URL:
>             Project: CouchDB
>          Issue Type: New Feature
>         Environment: Ubuntu 9.10 64bit
>            Reporter: Alexander Trauzzi
> It would be nice if CouchDB had a comprehensive offering for varying levels of access
to documents and databases.
> Here are some ideas:
> o User lists are stored in the database, per database.
> o Roles and role membership are stored in the database, per database.
> o ACLs are stored in the database, per database.
> o CouchDB can use ACLs to store and simplify permissions for internal functionality (manage
the db, manage users, add roles, add users to roles, etc...)
> o CouchApps can take advantage of the ACLs to support login/logout and arbitrary business
rules as needed.
> o A simple API can be made to conduct role, ACL and ownership checks.
> I suppose there is some theory and discussion behind determining whether users, roles
or both are stored in ACL rules.  Also, something worth discussing is whether the checks are
automatically performed by couchdb, or if views are to be performing checks prior to emitting
data.  Or both...
> Building all this into CouchDB would mean that it has a mechanism for complex applications
to be developed.  Ones that mandate privacy and other visibility concerns.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message