nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Wicks (pwicks)" <>
Subject RE: [EXT] Re: Moving UI objects on a parent you don't have access to
Date Wed, 01 Aug 2018 14:33:33 GMT

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.


-----Original Message-----
From: Matt Gilman [] 
Sent: Friday, July 27, 2018 7:46 PM
Subject: [EXT] Re: Moving UI objects on a parent you don't have access to


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.


On Fri, Jul 27, 2018 at 5:49 PM, Matt Gilman <>

> 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
>> * <>* 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
View raw message