Get policy for resource /policies/process-group returns incorrectly

[Amorik]

• Nipyapi version: 0.14.0
• NiFi version: 1.10.0
• NiFi-Registry version: N/A
• Python version: 3.6.8
• Operating System: Centos 7.x

Description

By default NiFi does not add any policies to the root canvas resource, so used nipyapi to do this for a handful of test accounts, including the initial admin. This worked for the majority of the resources with the exception of the /policies/process-groups/

Attempting to use the function get_access_policy_for_resource with the resource /policies/process-group results in the return of the policy of the global resource /policies.

Response should have been of the type None or if the argument auto_create was set to True create the policy and return it. If the policy was per-existing (created manually or via the UI) then the correct response is returned.

What I Did

Example Snippet:

root_pg_id = nipyapi.canvas.get_root_pg_id()
print(root_pg_id)  
policy = nipyapi.security.get_access_policy_for_resource('/policies/process-groups', 'write', r_id=root_pg_id, auto_create=False)
print(type(policy))
print(policy.component.resource)
print(policy)

Result:

cb732c4a-0170-1000-d466-6d9fc86ad506
<class 'nipyapi.nifi.models.access_policy_entity.AccessPolicyEntity'>
/policies
{'bulletins': None,
 'component': {'action': 'write',
               'component_reference': None,
               'configurable': True,
               'id': 'ad99ea98-3af6-3561-ae27-5bf09e1d969d',
               'parent_group_id': None,
               'position': None,
               'resource': '/policies',
               'user_groups': [],
               'users': [{'bulletins': None,
                          'component': {'configurable': True,
                                        'id': '6743d555-1f60-343a-9038-0be6fdcbf33b',
                                        'identity': 'CN=admin, OU=nifi',
                                        'parent_group_id': None,
                                        'position': None,
                                        'versioned_component_id': None},
                          'disconnected_node_acknowledged': None,
                          'id': '6743d555-1f60-343a-9038-0be6fdcbf33b',
                          'permissions': {'can_read': True, 'can_write': True},
                          'position': None,
                          'revision': {'client_id': None,
                                       'last_modifier': None,
                                       'version': 0},
                          'uri': None}],
               'versioned_component_id': None},
 'disconnected_node_acknowledged': None,
 'generated': '22:16:06 UTC',
 'id': 'ad99ea98-3af6-3561-ae27-5bf09e1d969d',
 'permissions': {'can_read': True, 'can_write': True},
 'position': None,
 'revision': {'client_id': None, 'last_modifier': None, 'version': 0},
 'uri': 'https://localhost:8443/nifi-api/policies/ad99ea98-3af6-3561-ae27-5bf09e1d969d'}

Note that setting auto_create to True ends in the same result. Between each test the authorizations.xml files was confirmed not to have changed and never contained the desired policy.

I have not tested this against other component-types.

Urgency

Not urgent.

To workaround the issue I've taken to using the create_access_policy and just ignore errors when attempting to create policies for /policies/process-group.

nipyapi.security.create_access_policy('/policies/process-groups', 'write', r_id=root_pg_id)

[kevdoran]

This is certainly odd behavior, and could be a bug. I'll dig into it and see what I can find...

[robdit]

We see the data for the global /policies resource because the root process group inherits it. The NiFi WebUI handles it by checking if the returned resource matches the requested one (Web UI Check). The bug is from the PoliciesApi get_access_policy_for_resource not performing that check. Not sure how you could fix it for the regular method as well as the callback one.

[ottobackwards]

~This is a bug in Nifi and it's API. The fact that the Nifi Web UI ( 1 specific client ) accounts for this is wrong. if the api provides it it is either right or an api bug~

[robdit]

Isn't this just a case of policy inheritance though? The root-pg starts with the global policies and you can override them through the API. This is the Jira issue that implemented the check for the Web UI.

[ottobackwards]

OK, I miss understood something. It is policy inheritance as you say. The method is documented as:

  """
        Gets an access policy for the specified action and resource
        Will return the effective policy if no component specific policy exists for the specified action and resource. Must have Read permissions to the policy with the desired action and resource. Permissions for the policy that is returned will be indicated in the response. This means the client could be authorized to get the policy for a given component but the effective policy may be inherited from an ancestor Process Group. If the client does not have permissions to that policy, the response will not include the policy and the permissions in the response will be marked accordingly. If the client does not have permissions to the policy of the desired action and resource a 403 response will be returned.
        This method makes a synchronous HTTP request by default. To make an
        asynchronous HTTP request, please define a `callback` function

So it is working as it is documented. The policy, though inherited is the policy for that component, so I think this api is working correctly. I think that the caller can perform the check as you found in the webui, or maybe a new higher level function the behaves the way you are expecting could work?