[ 
https://issues.apache.org/jira/browse/HDFS-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577165#comment-13577165
 ] 

Alejandro Abdelnur commented on HDFS-3367:
------------------------------------------

I was just looking at the code, I don't find in HDFS or HFTP FS client side any 
place where they are doing a doAs(), or in any FS client implementation. Jakob, 
where do you see that? 

My concern is that systems that use doAs() to impersonate users will break or 
work incorrectly with nested doAs() blocks. Oozie and HttpFS are examples of 
such systems.

The current implementation of WebHDFS obtains the UGI on FS client 
initialization time. This is exactly what HDFS FS client does. Once you have 
the FS handle you can exit the doAs() block where you go the FS client and the 
FS handle is still in the same UGI context. In the case of HDFS, the UGI 
information is used only when establishing the connection, after that all FS 
operations are done without any further UGI check. In the case of WebHDFS, to 
mimic this behavior, the current user UGI is obtained at initialization, cached 
and used on every request even if outside of the doAs() block that obtained the 
FS handle.

Unless I'm missing something I think the the current behavior is correct.

Any chance to have a simple example showcasing the issue? Then I could poke a 
bit.
                
> WebHDFS doesn't use the logged in user when opening connections
> ---------------------------------------------------------------
>
>                 Key: HDFS-3367
>                 URL: https://issues.apache.org/jira/browse/HDFS-3367
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: webhdfs
>    Affects Versions: 0.23.0, 1.0.2, 2.0.0-alpha, 3.0.0
>            Reporter: Jakob Homan
>            Assignee: Daryn Sharp
>            Priority: Critical
>         Attachments: HDFS-3367.branch-23.patch, HDFS-3367.patch
>
>
> Something along the lines of
> {noformat}
> UserGroupInformation.loginUserFromKeytab(<blah blah>)
> Filesystem fs = FileSystem.get(new URI("webhdfs://blah"), conf)
> {noformat}
> doesn't work as webhdfs doesn't use the correct context and the user shows up 
> to the spnego filter without kerberos credentials:
> {noformat}Exception in thread "main" java.io.IOException: Authentication 
> failed, 
> url=http://<NN>:50070/webhdfs/v1/?op=GETDELEGATIONTOKEN&user.name=<USER>
>       at 
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHttpUrlConnection(WebHdfsFileSystem.java:337)
>       at 
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.httpConnect(WebHdfsFileSystem.java:347)
>       at 
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.run(WebHdfsFileSystem.java:403)
>       at 
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getDelegationToken(WebHdfsFileSystem.java:675)
>       at 
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.initDelegationToken(WebHdfsFileSystem.java:176)
>       at 
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.initialize(WebHdfsFileSystem.java:160)
>       at 
> org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:1386)
> ...
> Caused by: 
> org.apache.hadoop.security.authentication.client.AuthenticationException: 
> GSSException: No valid credentials provided (Mechanism level: Failed to find 
> any Kerberos tgt)
>       at 
> org.apache.hadoop.security.authentication.client.KerberosAuthenticator.doSpnegoSequence(KerberosAuthenticator.java:232)
>       at 
> org.apache.hadoop.security.authentication.client.KerberosAuthenticator.authenticate(KerberosAuthenticator.java:141)
>       at 
> org.apache.hadoop.security.authentication.client.AuthenticatedURL.openConnection(AuthenticatedURL.java:217)
>       at 
> org.apache.hadoop.hdfs.web.WebHdfsFileSystem.getHttpUrlConnection(WebHdfsFileSystem.java:332)
>       ... 16 more
> Caused by: GSSException: No valid credentials provided (Mechanism level: 
> Failed to find any Kerberos tgt)
>       at 
> sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:130)
> ...{noformat}
> Explicitly getting the current user's context via a doAs block works, but 
> this should be done by webhdfs. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to