couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Per-DB Auth Ideas and Proposal
Date Thu, 10 Sep 2009 11:23:18 GMT
On Tue, Sep 08, 2009 at 06:41:19PM -0400, Adam Kocoloski wrote:
> I think it's actually pretty sensible to store some authz information in 
> the DB itself, for many of the same reasons outlined by Brian and  
> Benoit.  The big exception there is the ability to create new DBs.   

I would see it as being a bit like a validate_doc_update function in a
_design document: you could have authenticate and/or authorize functions
defined which apply to this database's subtree.

I'm not saying you should necessarily write them in Javascript. In the case
of authentication, I think you should select one of N built-in mechanisms
plus provide parameters to it. Mechanisms could include:
- fixed (provide a list of usernames/crypt passwords)
- authenticate against a couchdb database (this one or another one)
- authenticate against LDAP
etc

Ditto for authorisation, although maybe there's a case for having a
Javascript hook there too, if you don't mind the performance hit.

Then any access to /somedatabase/... would use what's in the database.
Only top-level functions would require per-node configuration, and I think
that should be configured in .ini. This would use the *same* set of
mechanisms defined as above: so the server-level authz could be a fixed set
of usernames/passwords for bootstrapping, or could be a special couchdb
database or whatever.

I guess these modules should be chainable, so that you can first try in a
couchdb database and if the user is not found, try the next module.

Regarding REST verbs: the problem I have with granting access based on REST
verbs and paths is that it ties the whole AAA setup to HTTP only. Perhaps
that's reasonable: it means that anyone who wants to work with couchdb at a
lower level (e.g. direct Erlang calls) will have to implement their own AAA.
And it does correspond to doing AAA in HTTP proxies, which is what people
are doing now anyway.

> Finally, there's the issue of authz in views.  What privileges does the 
> view indexer have?  If a user who is only allowed to read some of the 
> documents in the DB is allowed to upload a _design document, it seems to 
> me that the views generated from that _design document must exclude any 
> forbidden documents.  I guess this can work if the _design doc stores the 
> roles of the user who saved it.  It seems like a tricky, but solvable 
> problem.

That sounds very ugly. I think that we should only allow design documents to
be created by trusted users. Untrusted users who mess with design documents
can cause all sorts of trouble: at the minor end they can write views which
create huge resource utilisation, and at the major end with things like
erlview they can take over your entire system.

Regards,

Brian.

Mime
View raw message