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
