Matt,
I don't think you misinterpreted the first time. A few more examples:
- User has Read/Write permission to the process group but has only Read to
children:
Current: User cannot move children
Proposed: User can move all children on GUI
- User has Read only permissions to process group, but Read/Write permission
to children:
Current: User can move children
Proposed: User cannot move children
Hopefully that clarifies things, and I believe that lines right up with your
original read. I'm OK with saving this for a future release.
Ticket: https://issues.apache.org/jira/browse/NIFI-5477
-----Original Message-----
From: Matt Gilman [mailto:matt.c.gil...@gmail.com]
Sent: Friday, July 27, 2018 7:46 PM
To: dev@nifi.apache.org
Subject: [EXT] Re: Moving UI objects on a parent you don't have access to
Peter,
I just re-read your note and I realize that I may have misinterpreted your
question. I thought that you were asking to only enforce WRITE permissions on
the parent group. If this was the case, my previously stated concerns apply. If
we're looking to retain the component based checks and additionally introduce a
check on the parent group then my concerns don't apply. We certainly have other
endpoints that concern multiple components (like referencing controller
services for instance) which require multiple checks. However, they always
include the primary component as a basis for authorization. As long as we're
retaining the primary component check as well, we should be ok to introduce
this in a minor version release.
Matt
On Fri, Jul 27, 2018 at 5:49 PM, Matt Gilman <matt.c.gil...@gmail.com>
wrote:
> Please file the JIRA. I'm definitely not opposed to this change
> long-term, possibly in the next major release. I do have some concerns
> about introducing it in the near term. NiFi employs a fine grain
> authorization model where policies on each component drive access
> decisions. These resources map to the REST API resources. We treat our
> REST APIs and corresponding data models as public interfaces from a
> compatibility perspective (unless called out as non-guaranteed).
> Currently, clients can perform this action by changing the [x, y]
> coordinates on the component, invoking the component's REST endpoint,
> and being authorized to perform this action. The concerns I have are
> regarding this backward compatibility and existing clients and whether
> the update would leave the REST API and authorization scheme
> understandable/consumable. For instance, requiring the client to know
> that updating field A requires policy Y but updating field B requires policy
> Z.
>
> Matt
>
>
> On Fri, Jul 27, 2018 at 3:11 PM, Andy LoPresto <alopre...@apache.org>
> wrote:
>
>> Peter,
>>
>> I vaguely recall the conversations around (similar, not exactly the
>> same) permissions at the time this was implemented, and it was
>> decided to allow this due to time constraints. I do not object to
>> your proposal to change this (maybe Matt Gilman feels differently?).
>> If you open a Jira, it should be doable.
>>
>> Andy LoPresto
>> alopre...@apache.org
>> *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>* PGP
>> Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>
>> On Jul 27, 2018, at 9:32 AM, Peter Wicks (pwicks) <pwi...@micron.com>
>> wrote:
>>
>> While experimenting with permissions, I found that if I have no
>> permissions to a process group, but do have permissions to a child
>> that lives in that group, I can move that child around on the UI.
>>
>> I know that in the object model the x,y position values are part of
>> the child, which I have access to; but in this scenario it feels like
>> I'm allowed to modify things in a group where I have no permissions.
>> I propose that users can't move (x,y) objects if they do not have
>> modify access to the parent group. Thoughts?
>>
>> --Peter
>>
>>
>>
>
