[
https://issues.apache.org/jira/browse/HDFS-14434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16822024#comment-16822024
]
Kihwal Lee commented on HDFS-14434:
-----------------------------------
We can have the client selectively change the query param to "ugi.user.name".
This approach will allow unpatched servers to work with the new client and
still make servers log the useful information in their http request log.
{code:java}
@@ -81,4 +81,14 @@ public UserParam(final UserGroupInformation ugi) {
public String getName() {
return NAME;
}
+
+ public static class Ugi extends UserParam {
+ public Ugi(final String str) {
+ super(str);
+ }
+ @Override
+ public String getName() {
+ return "ugi."+super.getName();
+ }
+ }
}
{code}
So, it can be used like this:
{code:java}
if (securityEnabled) {
// for user name logging on the server-side.
authParams.add(new UserParam.Ugi(userUgi.getShortUserName()));
} else {
authParams.add(new UserParam(userUgi.getShortUserName()));
}
{code}
>From the server's perspective, it needs to be done only when a token is used,
>but we can't determine this reliably from the client side. When a file is
>created, the request is redirected to a datanode with an automatically issued
>token added to the redirect URL, if the client doesn't already have one (e.g.
>original request was using the kerberos auth). This request will be a
>token-based one, but will contain the original "user.name" param as well.
>Having the client manipulate redirect URLs is not ideal, so it will be easier
>to simply disable (i.e. use a modified query param) if security is enabled.
We also need to make sure that {{HttpFSServer}} is not doing something
unexpected and continue to be compatible with the modified
{{WebHdfsFileSystem}}.
> webhdfs that connect secure hdfs should not use user.name parameter
> -------------------------------------------------------------------
>
> Key: HDFS-14434
> URL: https://issues.apache.org/jira/browse/HDFS-14434
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Affects Versions: 3.1.2
> Reporter: KWON BYUNGCHANG
> Assignee: KWON BYUNGCHANG
> Priority: Minor
> Attachments: HDFS-14434.001.patch, HDFS-14434.002.patch
>
>
> I have two secure hadoop cluster. Both cluster use cross-realm
> authentication.
> [[email protected]|mailto:[email protected]] can access to HDFS of B.COM realm
> by the way, hadoop username of [email protected] in B.COM realm is
> cross_realm_a_com_user_a.
> hdfs dfs command of [email protected] using B.COM webhdfs failed.
> root cause is webhdfs that connect secure hdfs use user.name parameter.
> according to webhdfs spec, insecure webhdfs use user.name, secure webhdfs
> use SPNEGO for authentication.
> I think webhdfs that connect secure hdfs should not use user.name parameter.
> I will attach patch.
> below is error log
>
> {noformat}
> $ hdfs dfs -ls webhdfs://b.com:50070/
> ls: Usernames not matched: name=user_a != expected=cross_realm_a_com_user_a
>
> # user.name in cross realm webhdfs
> $ curl -u : --negotiate
> 'http://b.com:50070/webhdfs/v1/?op=GETDELEGATIONTOKEN&user.name=user_a'
> {"RemoteException":{"exception":"SecurityException","javaClassName":"java.lang.SecurityException","message":"Failed
> to obtain user group information: java.io.IOException: Usernames not
> matched: name=user_a != expected=cross_realm_a_com_user_a"}}
> # USE SPNEGO
> $ curl -u : --negotiate 'http://b.com:50070/webhdfs/v1/?op=GETDELEGATIONTOKEN'
> {"Token"{"urlString":"XgA....."}}
>
> {noformat}
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
