[
https://issues.apache.org/jira/browse/HDFS-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416866#comment-13416866
]
Eli Collins commented on HDFS-3639:
-----------------------------------
I've reverted this change (and HDFS-3654). Thanks to ATM who pointed out that
this "causes HftpFileSystem to not work at all with an actual secure cluster,
failing with an NPE when attempting to read a file. The reason being that both
DNs and NNs call JspHelper@getUGI, but it's 100% expected that in the DN case
that the context.getAttribute("name.node") will return null. In the NN case
(where "name.node" is set) it is needed for UGI verification."
Perhaps we should have a version of this function used by the NN that requires
the the name.node attribute be set and another version used by the NN that
doesn't verify the token?
> JspHelper#getUGI should always verify the token if security is enabled
> ----------------------------------------------------------------------
>
> Key: HDFS-3639
> URL: https://issues.apache.org/jira/browse/HDFS-3639
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: security
> Affects Versions: 1.0.0, 2.0.0-alpha
> Reporter: Eli Collins
> Assignee: Eli Collins
> Priority: Minor
> Fix For: 1.2.0, 2.1.0-alpha
>
> Attachments: hdfs-3639-b1.txt, hdfs-3639.txt
>
>
> JspHelper#getUGI on verifies the given token if the context and nn are set
> (added in HDFS-2416). We should unconditionally verifyToken the token, ie a
> bug where "name.node" is not set in the context object should not result in
> not verifying the token. In practice this shouldn't be an issue as per
> HDFS-3434 the context and NN should never be null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
