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