couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Pitman">
Subject Re: Security and Validation - Re: CouchDB 0.9 and 1.0
Date Tue, 08 Jul 2008 01:30:31 GMT
Thanks for your thoughts there, I'll definitely keep that in mind!
Personally I find the mySQL model overly annoying too, but I thought it was
a good place to start since it's "popular".  OK, well maybe not then :) ...
If you (or anyone here) knows of a database whose security model they DO
like, then feel free to post it here so I can take a look at that for
further inspiration ...

Thanks again and I will certainly be posting my results when I have
something that seems worthwhile.


On Mon, Jul 7, 2008 at 6:16 PM, Jan Lehnardt <> wrote:

> Disclaimer: It is Monday, I overslept and haven't had coffee yet. If I
> sound
> overly grupmy, that is the reason :)
> On Jul 7, 2008, at 05:29, David Pitman wrote:
> Just to let you know that I have been working on an "out-of-the-box
>> solution
>> for 1)" for a few weeks (in my spare time), mainly at this stage mapping
>> out
>> various schemes for how this could work and learning more about other
>> databases' authentication frameworks.  I figure if it is conceptually
>> similar (as far as convenient) to existing authentication frameworks such
>> as
>> what's used by mySQL, then developers will have an even easier learning
>> curve and find CouchDB yet more attractive.
> Please do _NOT_ model a security model after the MySQL security model.
> There are so many things wrong with it that I don't even know where to
> begin. Well, maybe, it is not that bad, but it is not easy to use and as
> a result everybody implements their own security custom scheme on top of
> MySQL and as a result, shared hosters give out only single MySQL accounts,
> because that's what everybody needs and as a direct result you can't share
> or
> move a userbase between two applications because, well, they have their
> own system. And as a bonus point: All security systems need to do the same
> thing over and over again and will introduce the same bugs over and over
> again.
> I don't want that happen to CouchDB :) It would be nice if CouchDB's
> security
> system would be exposed to a user & application for usage so they have a
> framework to do logins and permissions that all CouchDB applications can
> share. To avoid a) duplication of effort by writing yet another user
> management
> and permission system b) introduction of another two billion security
> systems
> that all have one bug or another and c) having to maintain two separate for
> two separate applications which is either a PITA for the user or admin.
> Yes out of the box would be nice, yes LDAP and other backends should be
> puginnable and yes this involves a lot of work and that's why we (at least
> I)
> want to keep that off 1.0.
> At the moment I'm prototyping in php and c++ (fast and easy), but once I've
>> established how I want it to work, I'm planning to start working with
>> Erlang
>> (I'm new to that).  I'll post up some details of my ideas once I've got a
>> nice fleshed-out concept that seems to work for me nicely.
>> I'm thinking of a kind of "out-of-the-box" plugin to the CouchDB which
>> adds
>> in the authentication layer, but which is not required by CouchDB to work.
>> Will let people know more when I've got something useful to show for my
>> efforts ...
> Ignoring the above: It would be really nice to see what you come up with
> here,
> please share your results :)
> Cheers
> Jan
> --
>> Thanks.
>> David.
>> On Thu, Jul 3, 2008 at 6:47 PM, Jan Lehnardt <> wrote:
>>> 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,
>>>>>> 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
>>>>>> 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 && != 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
>>>>>>> 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
>>>>>>> --
>> --
>> David Pitman

David Pitman

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message