[
https://issues.apache.org/jira/browse/MAPREDUCE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806800#action_12806800
]
Hemanth Yamijala commented on MAPREDUCE-899:
--------------------------------------------
Looking at the failed test results, I think we have hit HADOOP-4744 again, this
time though with NameNode.
We have these in the logs:
2010-01-30 16:02:53,658 INFO http.HttpServer (HttpServer.java:start(442)) -
Port returned by webServer.getConnectors()[0].getLocalPort() before open() is
-1. Opening the listener on 0
2010-01-30 16:02:53,659 INFO http.HttpServer (HttpServer.java:start(447)) -
listener.getLocalPort() returned 38815
webServer.getConnectors()[0].getLocalPort() returned 38815
2010-01-30 16:02:53,659 INFO http.HttpServer (HttpServer.java:start(480)) -
Jetty bound to port 38815
But then, the test itself fails like this:
{code}
java.lang.IllegalArgumentException: port out of range:-1
at java.net.InetSocketAddress.<init>(InetSocketAddress.java:118)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.startHttpServer(NameNode.java:377)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.activate(NameNode.java:317)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:308)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:421)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:410)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1261)
at org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:278)
at org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:127)
at
org.apache.hadoop.mapred.ClusterMapReduceTestCase.startCluster(ClusterMapReduceTestCase.java:81)
at
org.apache.hadoop.mapred.ClusterMapReduceTestCase.setUp(ClusterMapReduceTestCase.java:56)
{code}
Looking at the code in NameNode.startHttpServer, it looks like
httpServer.start() executed correctly, as indicated by the log line,
"listener.getLocalPort() returned 38815" above. Then httpServer.getPort() seems
to have returned -1. This is the same scenario that was described in
HADOOP-4744 and was worked around in Map/Reduce by failing the TaskTracker when
we hit this condition. We need a fix in Jetty or a workaround like in this in
DFS also to avoid the problem. I will open a separate JIRA for this.
The second testcase, IMO failed because the first did not finish correctly in
this case. Since in ClusterMapReduceTest, the dfsCluster is not initialized
correctly, I suppose a partial setup has happened, but the corresponding
cleanup did not, because ClusterMapReduceTest.teardown() would not have done
anything. And this resulted in the second test to fail.
Either way both test failures are unrelated to this patch.
> When using LinuxTaskController, localized files may become accessible to
> unintended users if permissions are misconfigured.
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-899
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-899
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: tasktracker
> Reporter: Vinod K V
> Assignee: Amareshwari Sriramadasu
> Fix For: 0.22.0
>
> Attachments: MAPREDUCE-899-20090828.txt, patch-899-1.txt,
> patch-899-2.txt, patch-899-3.txt, patch-899-4.txt, patch-899-5.txt,
> patch-899-6.txt, patch-899-7.txt, patch-899.txt, testplan.txt
>
>
> To enforce the accessibility of job files to only the job-owner and the
> TaskTracker, as per MAPREDUCE-842, it is _trusted_ that the setuid/setgid
> linux TaskController binary is group owned by a _special group_ to which only
> TaskTracker belongs and not just any group to which TT belongs. If the trust
> is broken, possibly due to misconfiguration by admins, the local files become
> accessible to unintended users, yet giving false sense of security to the
> admins.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
