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
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
> 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 *
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
>>
>> On Jul 27, 2018, at 9:32 AM, Peter Wicks (pwicks)
>> 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
>>
>>
>>
>
