> On 4. Apr 2019, at 00:25, Robert Samuel Newson <rnew...@apache.org> wrote:
>
> Hi,
>
> It’s sounds like we require a separate flag as to whether any given username
> or role may appear in such an informative 403 message. That is, wherever we
> sa that X is granted access, we have an optional flag on X to say if we can
> disclose its right of access to others, defaulting to false if not present.
If we make this a per-db setting, it shouldn’t be hard to add. If folks need to
have this work on a per-doc basis, I’m happy to argue that that should be done
outside of CouchDB :)
Best
Jan
—
>
> B.
>
>> On 3 Apr 2019, at 23:21, Adam Kocoloski <kocol...@apache.org> wrote:
>>
>> Totally agree it’s information leakage - that’s why I found it surprising
>> that this was their desired mode of operation. It works when there’s a
>> relatively small set of labels that get applied to data, and the labels
>> themselves are not all that confidential.
>>
>> Adam
>>
>>> On Apr 3, 2019, at 5:53 PM, Joan Touzet <woh...@apache.org> wrote:
>>>
>>> One parenthetical...
>>>
>>>> From: "Adam Kocoloski" <kocol...@apache.org>
>>>>
>>>> On a somewhat-related note, I have had conversations before with
>>>> folks who are keen to adopt these sorts of fine-grained access
>>>> control systems who said they actually prefer to have a 403
>>>> Forbidden response list the set of privileges that would be
>>>> sufficient to access the resource. I found this surprising, but I
>>>> guess it comes down to a user needing to figure out what kind of
>>>> security exception to apply for in order to make progress with some
>>>> data analysis. I think this is a topic on which we could make a
>>>> fairly late-binding decision — or even have it as a configurable
>>>> option.
>>>
>>> Anyone who's ever had to deal with Amazon's AWS IAM configuration
>>> certainly can appreciate this need. I'm +1 on the idea, assuming it's
>>> not hard to implement...but...
>>>
>>> The problem is that it can be a data leak. In Jan's initial gist, he
>>> shows the _access field being populated by usernames only (Scenario 1).
>>> The only possible exception here is to get your username added to the
>>> _access field on that document.
>>>
>>> If we do this via roles, then you could be leaking role name
>>> definitions via this response. Not sure we care, but having a full
>>> list of roles that could possibly provide that permission is certainly
>>> a hole.
>>>
>>> If we do this via _capability_, then you're looking at a set of
>>> permissions such as reader, writer, deleter, and that specific
>>> permission could be returned:
>>>
>>> {"needed":"writer", "obtained":"reader"}
>>>
>>> That'd work, but it's different from what Jan has proposed to date, I
>>> believe, especially in distinguishing between read, write, and delete.
>>>
>>> -Joan
>>
>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
