[
https://issues.apache.org/jira/browse/NIFI-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15951415#comment-15951415
]
ASF GitHub Bot commented on NIFI-3520:
--------------------------------------
Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/1635
@mcgilman Thanks for the review. I definitely agree that the current use of
`cloneDuringInstanceClassLoading` allows for some confusing situations to arise
and makes it challenging for the framework to try and prevent
incorrect/unexpected behavior.
Thinking about this some more... the main reason for creating that flag was
because at component creation time we only have the class name (String) and
bundle for the component, and we need to make a decision about how far to go up
the class loader hierarchy when cloning resources.
If we had an instance of the component already then we could use the same
logic we have in other places where we look at the property descriptors that
reference controller service APIs, and determine which bundle they came from,
and then stop cloning resources when that bundle is reached. We already have
temp instances of every component when performing the service loading so we
could potentially cache these instances to do a lookup by className+bundle, and
possibly even replace a lot of our other temp component creation with look ups
to these temp instances.
If we did the above we would be more aggressively cloning class loader
resources, essentially always cloning until we see controller service API
references. For cases where we don't want this behavior we could possibly
change the meaning of `cloneDuringInstanceClassLoading`. It could instead be
used on the NAR where the component with `@RequiresInstanceClassLoading` lives
to indicate that the ancestor resources should be considered (stopping at first
CS API as described above). If `cloneDuringInstanceClassLoading` isn't provided
or is set to false, then a component with `@RequiresInstanceClassLoading` only
gets a copy of it's own NAR resources.
Example 1 - `PutHDFS` has `@RequiresInstanceClassLoading` and
`nifi-hadoop-nar` has `cloneDuringInstanceClassLoading` set to true, so the
`InstanceClassLoader` for `PutHDFS` gets all the resources from
`nifi-hadoop-nar` back to the first NAR that has a CS API referenced by`
PutHDFS`, or back to `nifi-jetty-nar` (exclusive).
Example 2 - `HBaseClientService_1_1_2` has `@RequiresInstanceClassLoading`
and `nifi-hbase-client-service-1-1-2-nar` does not have
`cloneDuringInstanceClassLoading`, so the `InstanceClassLoader` for
`HBaseClientService_1_1_2` gets only the resources from
`nifi-hbase-client-service-1-1-2`.
Thoughts?
> HDFS processors experiencing Kerberos "impersonate" errors
> -----------------------------------------------------------
>
> Key: NIFI-3520
> URL: https://issues.apache.org/jira/browse/NIFI-3520
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.0.0, 1.1.0, 1.1.1, 1.0.1
> Reporter: Jeff Storck
> Assignee: Bryan Bende
> Fix For: 1.2.0
>
>
> When multiple Kerberos principals are used between multiple HDFS processors,
> the processor instances will be able to login to Kerberos with their
> configured principals initially, but will not properly relogin.
> For example, if there are two PutHDFS processors, one configured as
> us...@example.com, and the other as us...@example.com, they will both login
> with the KDC correctly and be able to transfer files to HDFS. Once one of
> the PutHDFS processors attempts to relogin, it may end up being logged in as
> the principal from the other PutHDFS processor. The principal contexts end
> up getting switched, and the hadoop client used by the processor will attempt
> to proxy requests from one user through another, resulting in the following
> exception:
> {panel}Failed to write to HDFS due to
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException):
> User: us...@example.com is not allowed to impersonate
> us...@example.com{panel}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
