couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stuart (SuperCoders)" <andrew.stu...@supercoders.com.au>
Subject Re: no 'writers' section in _security killing me
Date Mon, 11 Jul 2011 23:02:00 GMT
Okay I understand now I think - essentially "write only" access  
control for a given user is not built-in.  Seems like a good thing to  
be part of the basic security model - does anyone else agree, or is  
the general consensus that this is not something that should be part  
of the access control model?

as




On 12/07/2011, at 8:48 AM, Jonathan Geddes wrote:

Andrew,

There's nothing built in, but there are apparently a couple of possible
workarounds:

1. Use the '2.1 layer architecture': have something (like nodejs)  
listening
for changes on the public database that moves the data to a private  
database
and removes it from the public database.

2. Use the built-in rewriter to limit access to a given database to  
POST/PUT
(don't allow GET through)

--Jonathan

On Mon, Jul 11, 2011 at 4:27 PM, Andrew Stuart (SuperCoders) <
andrew.stuart@supercoders.com.au> wrote:

> Sorry I phrased that badly.
>
> Back in the days of Lotus Notes it was possible to have users who  
> were able
> to write into, but not read from a database.  Is similar  
> functionality built
> in to CouchDB or must it be enabled by external logic?
>
> as
>
>
>
>
> On 12/07/2011, at 7:48 AM, Robert Newson wrote:
>
> how would one replicate these write-only dropboxes?
>
> B.
>
> On 11 July 2011 22:13, Andrew Stuart (SuperCoders)
> <andrew.stuart@supercoders.**com.au  
> <andrew.stuart@supercoders.com.au>>
> wrote:
>
>> I've followed this thread but it's still somewhat unclear -
>>
>> -- is "write only" database access built in/easy to do, or must it be
>> enabled via some special external logic imposed at the application  
>> layer?
>>
>> as
>>
>> On 12/07/2011, at 6:39 AM, Jonathan Geddes wrote:
>>
>> One more possible solution: Could I use the rewriter to make sure  
>> that
>> that
>> only POST and PUT go through to a given database? How secure is this
>> approach?
>>
>> --Jonathan
>>
>> On Mon, Jul 11, 2011 at 8:45 AM, Jonathan Geddes
>> <geddes.jonathan@gmail.com>**wrote:
>>
>> Thanks for the responses, everyone.
>>>
>>> So I've been using CouchDB for about a year, but I'm only now  
>>> getting
>>> into
>>> the "2.1 Layer Architecture" (cutting back from a 3+ layer).
>>>
>>> Apparently I've been using readers and admins wrong all along. I  
>>> thought
>>> that only admins could write documents. After all, why would I  
>>> think that
>>> 'readers' could write? I've been a victim of the misnomer!
>>>
>>> I still think that the dropbox feature would be immensely useful,  
>>> and I
>>> still might take a whack at implementing it.
>>>
>>> Thanks for the clarification,
>>>
>>> --Jonathan
>>>
>>>
>>> On Mon, Jul 11, 2011 at 1:17 AM, Jason Smith <jhs@iriscouch.com>  
>>> wrote:
>>>
>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>> <geddes.jonathan@gmail.com> wrote:
>>>>
>>>>>
>>>>>> Fortunately, users with write access are not admins. They may not
>>>>>> modify design documents. All of their changes are subject to  
>>>>>> design
>>>>>> documents' validate_doc_update() function.
>>>>>>
>>>>>
>>>>> I would be *overjoyed* to hear that you are right and the  
>>>>> documentation
>>>>>
>>>>
>>>> at
>>>>
>>>>>
>>>>> [0] is wrong:
>>>>>
>>>>>>
>>>>>> database admins - Defined per database. They have all the  
>>>>>> privileges
>>>>>>
>>>>>
>>>>> readers have plus the privileges: write (and edit) design  
>>>>> documents,
>>>>> add/remove database admins and readers, set the database revisions
>>>>> limit
>>>>>
>>>>> (/somedb/_revs_limit API) and execute temporary views against the
>>>>>
>>>>
>>>> database
>>>>
>>>>>
>>>>> (/somedb/_temp_view API). They can not create a database and  
>>>>> neither
>>>>>
>>>>
>>>> delete
>>>>
>>>>>
>>>>> a database.
>>>>>
>>>>
>>>> D'oh, Marcello posted a pithy and timely answer while I had lunch.
>>>> I'll send anyway.
>>>>
>>>> The typical setup is:
>>>>
>>>> * 1 server admin
>>>> * 0 or more database admins (name or roles in _security.admins)
>>>> * An admin deploys a design document
>>>> * Several normal users (name or roles in _security.readers but  
>>>> *not*
>>>> admins)
>>>>
>>>> "readers" is a misnomer. It really means "members." Read access is
>>>> database-wide, write access is at the pleasure of
>>>> validate_doc_update().
>>>>
>>>> To that end, Chris changed CouchDB so that future releases will use
>>>> the "members" field. He committed his change last Thanksgiving
>>>> weekend. Thanks, Chris!
>>>>
>>>> I'm gonna set up a little experiment in the morning (when I can  
>>>> think
>>>>> clearly) to find out for myself. The _revs_limit PI and  
>>>>> temporary views
>>>>>
>>>>
>>>> are
>>>>
>>>>>
>>>>> scary too.
>>>>>
>>>>
>>>> I strongly encourage an experiment. 15 or 20 minutes of poking  
>>>> around
>>>> will make things very clear.
>>>>
>>>> Cloudant has a brilliant UI to impose more intuitive and  
>>>> traditional
>>>> security policies for exactly this reason.
>>>>
>>>> I call it a 2.5-layer architecture
>>>>>> because there is no middleware, but it still requires a third
>>>>>> component, to watch over things. The drop box would be amazing;
>>>>>> however I am still happy with my architecture because bugs or  
>>>>>> crashes
>>>>>> in the third component are not so devastating to the user  
>>>>>> experience.
>>>>>>
>>>>>
>>>>> The great thing about this architecture is that you can easily  
>>>>> have
>>>>>
>>>>
>>>> CouchDB
>>>>
>>>>>
>>>>> monitor the third party stuff and keep it running with external OS
>>>>>
>>>>
>>>> processes
>>>>
>>>>>
>>>>> [1]. I like the term '2.5-layer' :D.
>>>>>
>>>>
>>>> Is it too late to change the name to "2.1-layer"?
>>>>
>>>> * Hints that the extra step is not going to break your back
>>>> * Kind of like 5.1 surround sound
>>>>
>>>> By the way, why hasn't this been implimented before? It seems  
>>>> strange
>>>>> to
>>>>>
>>>>
>>>> me.
>>>>
>>>>>
>>>>> Is there something inherent in the architecture of CouchDB that  
>>>>> makes
>>>>>
>>>>
>>>> this
>>>>
>>>>>
>>>>> difficult?
>>>>>
>>>>
>>>> I think it is a matter of time. The people in a position to  
>>>> implement
>>>> it have not felt quite enough pressure.
>>>>
>>>> /me whistles innocently.
>>>>
>>>> --
>>>> Iris Couch
>>>>
>>>>
>>>
>>> --
>> Message  protected by MailGuard: e-mail anti-virus, anti-spam and  
>> content
>> filtering.http://www.**mailguard.com.au/mg<http://www.mailguard.com.au/mg 
>> >
>> Click here to report this message as spam:
>> https://login.mailguard.com.**au/report/1CGUOUsAWN/**
>> 2BVxdPfDhfeJK4SLOnz0gl/1<https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1

>> >
>>
>> --
> Message  protected by MailGuard: e-mail anti-virus, anti-spam and  
> content
> filtering.http://www.**mailguard.com.au/mg<http://www.mailguard.com.au/mg 
> >
> Click here to report this message as spam:
> https://login.mailguard.com.**au/report/1CGW2fhE4N/**
> 5SE2wTOEjJss04ObshZ4q9/1<https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1

> >
>

Mime
View raw message