[
https://issues.apache.org/jira/browse/MAPREDUCE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797537#action_12797537
]
Vinod K V commented on MAPREDUCE-899:
-------------------------------------
Looked at the patch. Some comments I have:
- main.c : We should check _errno_ after the statement (+131) {{int ngroups =
getgroups (0, NULL);}} and return immediately on error. If there is no error,
we should (of course) reset _errno_ to zero for further ops.
- {{TTConfig.TT_TASK_CONTROLLER_GROUP}} seems to be only for internal use. In
that case, let's not even put it in there and instead put it possibly in
{{ClusterWithLinuxTaskController}}. Correspondingly we will not need the
documentation changes in mapred-default.xml
- We should also update the forrest documentation regarding this change.
ClusterWithLinuxTaskController.java
- {{createTaskControllerConf()}} can either (1) take the group name itself as
an argument instead of a whole conf object or (2) only take a conf object and
extract both local-dirs and group name from the conf object.
- Instead of giving the default value of
{{System.getProperty(TASKCONTROLLER_PATH)+ "/task-controller"}} to
{{taskControllerExePath}}, you can use {{setTaskControllerExe()}} whenever
needed.
- As for the changes to generate the {{taskcontroller.cfg}} file here and in
{{MiniMRCluster}}, I think there is a lot easier way of doing this which avoids
the changes to {{MiniMRCluster}}
-- For general ClusterWithLinuxTaskController tests, we can disable the
binary checks by overriding LinuxTaskController.setup() method and can then
simply generate the configuration file after the cluster starts so that further
checks done when tasks are launched can go smoothly.
-- The changes to the tests in the current patch already test that the
checks are done successfully during task startup. To verify the checks during
TT startup, we can add simple unit tests which just start the TT with/without
group name and with invalid group name.
Does that work?
- Currently, number of TTs is a final constant 1 in this class. It doesn't
really suport more nodes in that each TT will then need its own copy of binary
file. This is because a binary is tied to a config file. So the multiple TTs
case won't work with multiple configs but a single binary. Should we copy the
binary to each TT's space and generate multiple configs? Or leave it as is and
comment on NUMBER_OF_NODES saying to change it to more than 1, we will need
more changes?
Nits:
- taskcontroller.cfg: Can you modify the comment for
mapreduce.tasktracker.taskcontroller.group to be "The group owner of the task
controller binary"?
- LinuxTaskController: In setp() method, can you change the log statement @114
to warn level and enhance the log statement too saying {{setup()}} failed
because of invalid permissions/ownership on the binary?
> 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.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.
