couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keno Kuhlmann <keno.kuhlm...@gmx.de>
Subject Re: Disabling doc include
Date Thu, 02 Jan 2014 14:02:54 GMT

On 02/01/2014, at 14:35, Benoit Chesneau <bchesneau@gmail.com> wrote:

> On Thu, Jan 2, 2014 at 2:29 PM, Keno Kuhlmann <keno.kuhlmann@gmx.de> wrote:
> 
>> Happy 2014 @ the list,
>> 
>> there is no document level (or even worse attribute level) access control
>> mechanism implemented in couched at this time, please correct me if I am
>> wrong. Any type of document level access control introduces problems with
>> either information leaking aggregate/reduce functions or plain wrong query
>> results. It does not matter if implemented inside couchdb or elsewhere.
> 
> 
> 
> not sure what you mean there.

When using aggregate functions, e.g. count, counting all documents results either in leaking
information (in case documents are counted that you do not have read access to) or the result
is wrong (count reveals 2 documents, but in the db are much more). From a users point of view,
it does not matter wether this behavior is introduced by couchdb code or somewhere else. In
a lot of cases this is even what the user expects. For the App-developer it might be handy
to have some functionality inside couchdb to avoid an external access control layer. validate_read
might just be such a handy function. Filtering out GET (read) request on the http layer based
on some document attributes might be helpful in some other cases.

 

> 
> 
>> Anyhow, many applications require access control, maybe we should collect
>> some ideas, best practices or implement some helping functions, such as
>> validate_read, rewrite/vhost layer, etc.
>> 
> You mean like  :
> 
> https://github.com/refuge/rcouch/wiki/Validate-documents-on-read
> 
> ?
> 
> 

yes

> 
> 
>> Keno
>> 
>> On 02/01/2014, at 13:27, Stanley Iriele <siriele2x3@gmail.com> wrote:
>> 
>>> Correct me if I'm wrong here... If every doc had some meta info with
>> it...
>>> And every URL rewrite went to a show or list function...couldn't you use
>>> the sec object passed on the request object to get what you want?... Or
>>> pass in some application level user credentials... Granted that doesn't
>>> sound very elegant
>>> On Jan 2, 2014 7:22 AM, "Robert Newson" <rnewson@apache.org> wrote:
>>> 
>>>> 
>>>> It doesn’t achieve the same effect, though, the virtual host + url
>>>> rewriter is not an access control mechanism. You’re still granting
>>>> database-wide read permissions to the user.
>>>> 
>>>> B.
>>>> 
>>>> 
>>>> On 2 Jan 2014, at 09:09, Florian Westreicher Bakk.techn. <
>>>> stuff@meredrica.org> wrote:
>>>> 
>>>>> I put a design doc behind a desk record / virtual host, that should do
>>>> the trick. The user that is used by the app is read only
>>>>> 
>>>>> Robert Newson <rnewson@apache.org> wrote:
>>>>>> "there’s no notion of read-protection in CouchDB."
>>>>>> 
>>>>>> There’s no document level read protection, but you can certainly
grant
>>>>>> or deny read access to users on a per database basis. That’s by
design
>>>>>> due to the ease that information could leak out through views
>>>>>> (particularly reduce views). The restrictive proxy approach is
>> brittle,
>>>>>> it requires that you know all the URL patterns to block and keep
them
>>>>>> up to date when you upgrade CouchDB. It can work, it’s just not
>>>>>> awesome.
>>>>>> 
>>>>>> B.
>>>>>> 
>>>>>> .
>>>>>> 
>>>>>> On 1 Jan 2014, at 20:47, Jens Alfke <jens@couchbase.com> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Dec 31, 2013, at 1:44 AM, meredrica <stuff@meredrica.org>
wrote:
>>>>>>> 
>>>>>>>> I expose CouchDB directly to mobile clients and wanted to
hide some
>>>>>>>> information from them.
>>>>>>> 
>>>>>>> You can’t really do that; there’s no notion of read-protection
in
>>>>>> CouchDB.
>>>>>>> As a workaround you can put CouchDB behind a proxy or gateway,
and
>>>>>> restrict the URL patterns that clients are allowed to send.
>>>>>>> 
>>>>>>> —Jens
>>>>>>> 
>>>>> 
>>>>> --
>>>>> Sent from Kaiten Mail. Please excuse my brevity.
>>>> 
>>>> 
>> 
>> 


Mime
View raw message