nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy LoPresto <alopre...@apache.org>
Subject Re: Policy to clear queues
Date Thu, 04 Jun 2020 23:50:23 GMT
Do the node identities themselves have the proper permissions as well? The following is from
the Admin Guide: 

> In order to access List Queue or Delete Queue for a connection, a user requires permission
to the "view the data" and "modify the data" policies on the component. In a clustered environment,
all nodes must be be added to these policies as well, as a user request could be replicated
through any node in the cluster.


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 4, 2020, at 4:45 PM, Phil H <gippyphil@gmail.com> wrote:
> 
> The action is available in the menu. I get the following pop up:
> 
> *Insufficient Permissions*
> 
> *Node nifiX.domain.com:443 <http://nifiX.domain.com:443> is unable to
> fulfil this request due to: Unable to modify the data for Processor with ID
> {guid}. Contact the system administrator. Contact the system administrator.*
> 
> The nifi-user.log just shows successful authentication events for the user
> in question (the system is locked down to authorized users)
> 
> Phil
> 
> On Fri, 5 Jun 2020 at 09:25, Andy LoPresto <alopresto@apache.org> wrote:
> 
>> Are you seeing this behavior exhibited as the action is not even available
>> to those users, or when they try to execute it, it returns an error? Can
>> you examine the logs/nifi-user.log file to see if the authorization is
>> occurring successfully?
>> 
>> 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 4, 2020, at 4:22 PM, Phil H <gippyphil@gmail.com> wrote:
>>> 
>>> 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