-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.

Hadoop QA
added a comment - 27/Sep/11 04:24 -1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12496624/HDFS-2361.trunk.1.patch
against trunk revision .
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
-1 javac. The patch appears to cause tar ant target to fail.
-1 findbugs. The patch appears to cause Findbugs (version 1.3.9) to fail.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
+1 core tests. The patch passed unit tests in .
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/1295//testReport/
Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1295//console
This message is automatically generated.

-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of release audit warnings.

Hadoop QA
added a comment - 27/Sep/11 10:38 -1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12496649/HDFS-2361.trunk.2.patch
against trunk revision .
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hdfs.TestDfsOverAvroRpc
org.apache.hadoop.hdfs.server.blockmanagement.TestHost2NodesMap
org.apache.hadoop.hdfs.server.datanode.TestReplicasMap
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/1297//testReport/
Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1297//console
This message is automatically generated.

That's correct. It is assumed that short-names will be unique across users.
KerberosAuthenticationHandler sets only the short name in the request, therefore only short name is available in JspHelper#getUGI in case of kerberos spnego authentication.

Jitendra Nath Pandey
added a comment - 27/Sep/11 16:47 That's correct. It is assumed that short-names will be unique across users.
KerberosAuthenticationHandler sets only the short name in the request, therefore only short name is available in JspHelper#getUGI in case of kerberos spnego authentication.

Does this weaken the security of hadoop? Are there other safeguards to prevent a user in one realm from accessing the files of an identically named user in a different realm? If not, is it correct that multiple-realm installations now have a vulnerability due to what I believe you are saying is a spnego limitation?

Daryn Sharp
added a comment - 27/Sep/11 21:32 Does this weaken the security of hadoop? Are there other safeguards to prevent a user in one realm from accessing the files of an identically named user in a different realm? If not, is it correct that multiple-realm installations now have a vulnerability due to what I believe you are saying is a spnego limitation?

There is a comment in the code: "The realm can be omitted from the principal as the JDK GSS libraries will use the realm name of the configured default realm". It would appear that this jira may be due to an arbitrary, and maybe unnecessary, implementation decision?

Daryn Sharp
added a comment - 27/Sep/11 22:18 Would it be better to change this to not use getShortName() ?
KerberosAuthenticationHandler
KerberosName kerberosName = new KerberosName(clientPrincipal);
String userName = kerberosName.getShortName();
token = new AuthenticationToken(userName, clientPrincipal, TYPE);
There is a comment in the code: "The realm can be omitted from the principal as the JDK GSS libraries will use the realm name of the configured default realm". It would appear that this jira may be due to an arbitrary, and maybe unnecessary, implementation decision?

It is not a spnego implementation. KerberosAuthenticationHandler is one example where we use shortnames. There are other places as well in hadoop, where it was assumed that it is sufficient to use shortnames, for example proxy user configuration, in checking file permissions etc.

Jitendra Nath Pandey
added a comment - 28/Sep/11 02:10 It is not a spnego implementation. KerberosAuthenticationHandler is one example where we use shortnames. There are other places as well in hadoop, where it was assumed that it is sufficient to use shortnames, for example proxy user configuration, in checking file permissions etc.

> It is not a spnego implementation.
Correction: It is not a spnego limitation.

That said, it can be debated (and has been debated before) whether we want to switch to long names consistently in hadoop. But that requires revisiting, all the contexts where we assumed shortnames were sufficient.

Jitendra Nath Pandey
added a comment - 28/Sep/11 02:18 > It is not a spnego implementation.
Correction: It is not a spnego limitation.
That said, it can be debated (and has been debated before) whether we want to switch to long names consistently in hadoop. But that requires revisiting, all the contexts where we assumed shortnames were sufficient.

The patch was manually tested on a secure cluster in branch-0.20-security.
This issue showed up only in a secure cluster, and the code change in the patch takes effect only if security is enabled. Therefore, tests require a secure setup.

Jitendra Nath Pandey
added a comment - 28/Sep/11 06:26 The patch was manually tested on a secure cluster in branch-0.20-security.
This issue showed up only in a secure cluster, and the code change in the patch takes effect only if security is enabled. Therefore, tests require a secure setup.