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.
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
>
