Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-dev@incubator.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 drpitman@wherebi.com does not designate 209.85.200.172 as permitted sender)
Message-ID: <5e33bf2e0807071830w607fc89t40603f34bd9058f7@mail.gmail.com>
Date: Tue, 8 Jul 2008 11:30:31 +1000
From: "David Pitman" <me@davidpitman.name>
Sender: drpitman@wherebi.com
To: couchdb-dev@incubator.apache.org
Subject: Re: Security and Validation - Re: CouchDB 0.9 and 1.0
In-Reply-To: <7CC99459-09FC-49B9-A17B-0F74A0ADAD05@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_14587_28843412.1215480631820"
References: <7D76E702-4BB8-42FD-8704-9E8BA70F95BC@apache.org>
	 <88A14D9C-5C6A-4EFE-A4C4-6F1ADD81A1F2@gmail.com>
	 <20080702174410.GB28311@bytesexual.org>
	 <486BC531.9060209@smokejumperit.com>
	 <626608DF-6077-4982-BB74-E126BDBBE62A@apache.org>
	 <5e33bf2e0807062029r5077c111xbd7d663bbbe064d0@mail.gmail.com>
	 <7CC99459-09FC-49B9-A17B-0F74A0ADAD05@apache.org>

------=_Part_14587_28843412.1215480631820
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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.

David.


On Mon, Jul 7, 2008 at 6:16 PM, Jan Lehnardt <jan@apache.org> 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 <jan@apache.org> 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, 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
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> David Pitman
>> www.davidpitman.name
>>
>
>


-- 
David Pitman
www.davidpitman.name

------=_Part_14587_28843412.1215480631820--