nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil H <gippyp...@gmail.com>
Subject Re: Policy to clear queues
Date Thu, 04 Jun 2020 23:22:04 GMT
Hi guys,

So I checked this morning, and the users are members of a group that has
“modify the data” permission at the root level (and is inherited within the
process group). They can start/stop processors, but cannot empty (or even
list) the queues in said process group.

I also set up a queue at the root level and confirmed the same behaviour
there.

Thanks

On Thu, 4 Jun 2020 at 23:22, Bryan Bende <bbende@gmail.com> wrote:

> Would also add that if you don't have specific component policies on
> processors, it should inherit from the process group. So at the process
> group level you can give some users write to the actual process group which
> should control creating/deleting connections, and give some users only
> modify the data on the process group which would control clearing queues.
>
> On Thu, Jun 4, 2020 at 8:55 AM Mark Bean <mark.o.bean@gmail.com> wrote:
>
> > Phil,
> >
> > There is a 'modify the data' Component Access Policy. Use the key icon in
> > the Operate palette (or right-click on the component) to access the
> > Component Access Policies as opposed to using the Global Menu in the
> upper
> > right to access Global Access Policies.
> >
> > The user will be able to empty a queue if they are in the 'modify the
> data'
> > policy for the upstream component (processor) which generated the data.
> > This policy does not allow the user to delete the connection between
> > processors. To do so requires the 'modify the component' policy.
> >
> > One additional nuance to consider: if you are operating a NiFi Cluster,
> you
> > will need to add each of the cluster nodes to the 'modify the data'
> policy
> > as well. This is required because the request to empty a queue is proxied
> > from the node being used to access the UI out to the remaining nodes.
> >
> > -Mark
> >
> >
> > On Thu, Jun 4, 2020 at 6:52 AM Phil H <gippyphil@gmail.com> wrote:
> >
> > > Hi Andy,
> > >
> > > Thanks for your reply. I don’t recall seeing the modify data policy in
> > the
> > > user interface. Is it possible this is something I would have to change
> > at
> > > the back end?
> > >
> > > I don’t have the system in front of me now, will have to confirm
> > tomorrow.
> > >
> > > Regards,
> > > Phil
> > >
> > > On Thu, 4 Jun 2020 at 11:18, Andy LoPresto <alopresto@apache.org>
> wrote:
> > >
> > > > Hi Phil,
> > > >
> > > > You might have uncovered a gap in the permission policy. Have you
> tried
> > > > using the “modify the data” permission [1]? If a user does not have
> > write
> > > > permission to the queue, I think they can empty it but not
> > modify/delete
> > > > the queue itself.
> > > >
> > > > I am speculating here because I haven’t had a chance to verify, but
I
> > > > suspect that the same write permission which allows a user to clear
> the
> > > > queue would allow them to delete it as well. This may be something we
> > > could
> > > > mitigate by using the “operate” permission, but I would have to
> > validate
> > > > this behavior first.
> > > >
> > > > Hope this helps for now.
> > > >
> > > > [1]
> > > >
> > >
> >
> https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#component-level-access-policies
> > > >
> > > > Andy LoPresto
> > > > alopresto@apache.org
> > > > alopresto.apache@gmail.com
> > > > He/Him
> > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > > >
> > > > > On Jun 3, 2020, at 4:08 PM, Phil H <gippyphil@gmail.com> wrote:
> > > > >
> > > > > Hi there,
> > > > >
> > > > > I am trying to stratify my userbase. I need to allow certain
> > > users/groups
> > > > > the ability to clear queues, but cannot find the right policy to
> > allow
> > > > that
> > > > > without also allowing them to delete queues, which I absolutely
> don’t
> > > > want
> > > > > to do.
> > > > >
> > > > > Am currently using 1.9.2 (putting off the upgrade process!)
> > > > >
> > > > > Regards,
> > > > > Phil
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message