Peter, In that case, I am actually opposed to this proposal. I read it initially the way Matt did on his second reading — to move a component, you (would) need write access to that component AND to the parent. I am ok with requiring an *additional* write requirement, but I feel to be able to move a component without having write access to it goes against the intent and implementation of our policies.
Andy LoPresto alopre...@apache.org alopresto.apa...@gmail.com PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Aug 1, 2018, at 7:33 AM, Peter Wicks (pwicks) <pwi...@micron.com> wrote: > > 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 >>> >>> >>> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
