incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Date Thu, 03 Jul 2008 08:47:09 GMT

On Jul 2, 2008, at 20:13, Robert Fischer wrote:

> Two points.
>
> 1) I'd encourage the CouchDB group to stick to authorization and  
> leave authentication to proxies at
> this point.  If you have some free time in the future, maybe you can  
> think about integrating an
> authentication layer -- but there's a lot more critical  
> functionality needed, and an HTTP proxy can
> handle it just fine for the time being.  If you consider that  
> username/password authentication is
> inherently evil, and "real" authentication servers are built off of  
> LDAP, kerberos, or the like,
> then the massive amount of work involved in doing authentication  
> should be clear.  And this isn't
> even getting into the likelihood that a new authentication  
> implementation will probably get some
> stuff wrong in non-trivial, non-obvious ways.  So, please, let  
> authentication be handled by proxies.
>
> 2) In terms of authorization, it would be nice if there was a  
> concept of "read only" and
> "read-write" premissions at the database level.  MySQL goes a bit  
> nuts with their permissions
> possibly going all the way down to the column level, but it's nice  
> to have that distinction at the
> database level.  This means I can guaranty I don't accidentally  
> modify something when I just mean to
> be querying it: this kind of functionality has saved my butt a  
> number of times in the past ("Why is
> this update failing on my dev box?  Oh...wait...that's my production  
> terminal window!"), and it
> would be sad to see it left out.

+1 on both accounts.

For the long term, it'd be nice to have an out-of-the-box
solution for 1), but we shouldn't focus on this now.

Cheers
Jan
--


>
>
> Of course, I could do that kind of permission setting at the Apache  
> level, too, by defining the
> routes as locations and setting permissions -- but it'd probably be  
> both cleaner and more
> appropriate to be done in the DB itself.
>
> ~~ Robert.
>
> Noah Slater wrote:
>> Perhaps we could rely on standard HTTP auth either:
>>
>> * as passed back through a proxy
>> * as negotiated by CouchDB using a similar method to Apache httpd
>>
>> This doesn't seem too hard, Mochiweb might even support it natively.
>>
>> On Wed, Jul 02, 2008 at 12:56:44PM -0400, Damien Katz wrote:
>>> We need to implement a couchdb security model. I think at a high  
>>> level
>>> it should be simple as possible. Also I think we won't do
>>> authentication, that should be handled by a authenticating proxy, or
>>> application code.
>>>
>>> I'm thinking our model looks something like this:
>>>
>>> We'll have server wide admin accounts, and dbadmin accounts. Db  
>>> Admins
>>> can create dbs and admin their own dbs. Server admins are like
>>> superusers. Only admins are allowed to update design documents in
>>> databases.
>>>
>>> The per-database customized module will be supported by custom
>>> validation functions contained in databases design documents.   
>>> When a
>>> document is updated, either via replication or new edit, these
>>> validation functions are evaluate with provided context.
>>>
>>> Here is a very simplistic validation routine:
>>>
>>> function (doc, ctx) {
>>>      if (doc.type == "topic" && doc.subject == undefined) {
>>>              throw "Error, a subject is required for all topics.";
>>>      }
>>> }
>>>
>>> Something that looks at previous revisions:
>>>
>>> function (doc, ctx) {
>>>      var prev = ctx.get_local_doc();
>>>      if (prev != null && prev.author != ctx.user_name()) {
>>>              throw "Error, update by non-author.";
>>>      }
>>> }
>>>
>>> It should also be possible modify the document while it's being  
>>> saved,
>>> but this might only be allowable when its a new edit, vs a  
>>> replicated
>>> update or backup restore.
>>>
>>> All further security schemes would be handled the customized  
>>> functions,
>>> and though APIs to do database or external ldap queries.
>>> On Jul 2, 2008, at 3:08 AM, Jan Lehnardt wrote:
>>>
>>>> Hello everybody,
>>>> this thread is meant to collect missing work items (features and
>>>> bugs) for for our 1.0 release and a discussion about how to split
>>>> them up between 0.9 and 1.0.
>>>>
>>>> Take it away: Damien.
>>>>
>>>> Cheers
>>>> Jan
>>>> --
>>
>


Mime
View raw message