[
https://issues.apache.org/jira/browse/NIFI-4907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504908#comment-16504908
]
ASF GitHub Bot commented on NIFI-4907:
--------------------------------------
Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/2703
@markobean I just ran your PR and I'm not seeing the same behavior you are
describing. Even without the component policy, I'm able to view the provenance
event. This is the behavior I was expecting to see following the discussion on
the JIRA. It's possible that we're using the same language to refer to
different things. Let me try to elaborate/clarify a bit here.
/processors/1234 - component policy (controls access to a component and its
config)
/provenance-data/processors/1234 - comopnent provenance event policy
(controls access to the provenance events from a component)
/data/processors/1234 - component data policy (controls access to the data
from a component including flowfile attributes)
The line you referenced should only verify access to the component
provenance event (and it appears that's how it's working). It should not be
checking the component policy. My suggestion was to additionally check the
component policy prior to populating the component details
(`setComponentDetails`). This would be in line with your initial comment on
this JIRA.
With your most recent changes, I'm not sure its functionality is different
than before. It seems that it would be impossible to get a non-summarized event
without permissions to the data of the component. I think we only need to
verify permissions to data of a component for the attributes and the content
specific fields. Other fields should be ok, allowing for a non-summarized event
for folks without access to a component's data.
It appears that `checkAuthorizationForReplay` was also verifying that the
connection that would be replayed into still exists. This would affect the
availability of the replay action. Also, while a little nit-picky, I would also
suggest using the `checkAuthorization...` methods which return an
`AuthorizationResult` instead of relying on an `Exception` during a
non-exceptional case. The generation of the stack trace is an expensive
operation.
Also, it does not seem like you updated or replied to my comment regarding
the need to include the flowfile attributes when authorizing access to
component's provenance events. I think these are only necessary when
authorizing access to a component's data.
Please do not squash additional commits. It makes it difficult to review
when I cannot easily see the incremental changes.
Thanks!
> Provenance authorization refactoring
> ------------------------------------
>
> Key: NIFI-4907
> URL: https://issues.apache.org/jira/browse/NIFI-4907
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.5.0
> Reporter: Mark Bean
> Assignee: Mark Bean
> Priority: Major
>
> Currently, the 'view the data' component policy is too tightly coupled with
> Provenance queries. The 'query provenance' policy should be the only policy
> required for viewing Provenance query results. Both 'view the component' and
> 'view the data' policies should be used to refine the appropriate visibility
> of event details - but not the event itself.
> 1) Component Visibility
> The authorization of Provenance events is inconsistent with the behavior of
> the graph. For example, if a user does not have 'view the component' policy,
> the graph shows this component as a "black box" (no details such as name,
> UUID, etc.) However, when querying Provenance, this component will show up
> including the Component Type and the Component Name. This is in effect a
> violation of the policy. These component details should be obscured in the
> Provenance event displayed if user does not have the appropriate 'view the
> component' policy.
> 2) Data Visibility
> For a Provenance query, all events should be visible as long as the user
> performing the query belongs to the 'query provenance' global policy. As
> mentioned above, some information about the component may be obscured
> depending on 'view the component' policy, but the event itself should be
> visible. Additionally, details of the event (clicking the View Details "i"
> icon) should only be accessible if the user belongs to the 'view the data'
> policy for the affected component. If the user is not in the appropriate
> 'view the data' policy, a popup warning should be displayed indicating the
> reason details are not visible with more specific detail than the current
> "Contact the system administrator".
> 3) Lineage Graphs
> As with the Provenance table view recommendation above, the lineage graph
> should display all events. Currently, if the lineage graph includes an event
> belonging to a component which the user does not have 'view the data', it is
> shown on the graph as "UNKNOWN". As with Data Visibility mentioned above, the
> graph should indicate the event type as long as the user is in the 'view the
> component'. Subsequent "View Details" on the event should only be visible if
> the user is in the 'view the data' policy.
> In summary, for Provenance query results and lineage graphs, all events
> should be shown. Component Name and Component Type information should be
> conditionally visible depending on the corresponding component policy 'view
> the component' policy. Event details including Provenance event type and
> FlowFile information should be conditionally available depending on the
> corresponding component policy 'view the data'. Inability to display event
> details should provide feedback to the user indicating the reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
