hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hemanth Yamijala (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-4491) Per-job local data on the TaskTracker node should have right access-control
Date Mon, 13 Jul 2009 05:08:14 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730216#action_12730216

Hemanth Yamijala commented on HADOOP-4491:

I would like to call out some approaches this patch is taking explicitly, so that there's
an opportunity for discussion:

h4. 1. Setting secure permissions by default vs doing so only in the LinuxTaskController

The patch sets permissions for localized job files and directories as part of the localization
process itself, that is as soon as the files are localized, rather than in the TaskController.
I believe this approach was taken primarily to secure permissions on the localized files on
the disk ASAP. The effect of doing so is that now all configurations of hadoop, including
those which do not worry about security will have secure permissions for some of the files.
While this should be OK in principle, it must be noted that without the entire solution offered
by the LinuxTaskController, full security is not achieved. Hence, does it make sense to make
changes to the permissions only when using the LinuxTaskController (with a small window where
files could have potentially insecure permissions), and leave the default case alone ?

Either way, I think the current method in which permissions are changed for the localized
files causes these to be splattered across the code. It may lead to mistakes in future if
somebody is making changes (say to localize a new file) and is not fully aware of the permissions
issue. Ideally it should be abstracted from the process. In speaking with Vinod about this,
I realized this may not be very easy to achieve the way LocalDirAllocator currently works.
If we keep the changes to the task controller alone, I believe this will be very easy to accomplish.

h4. 2. Approach for sharing common files between TT and child

The patch juggles around with permissions on the localized and intermediate files by first
setting ownership to the job owner, and after the task is complete, changing the ownership
back to the tasktracker user. The reason it does this, is for two purposes:
-- To enable intermediate outputs to be served by the tasktracker, once the child has created
-- To allow cleanup as the tasktracker once the tasks are done.

Note that change of ownership is done by launching the task-controller setuid binary as root
privileges are required for the purpose.

The above two problems can be solved in another way as well (and this is what was discussed
on HADOOP-4490). In that approach, we'd thought of moving the intermediate outputs to a different
directory owned by the tasktracker, and we'd thought of removing files and directories as
the user, as part of the cleanup thread. I think one advantage this alternative approach brings
is that it gives an opportunity to not launch the task-controller for reduces and hence slots
can become free sooner. This does mean the cleanup might take more time, but that happens

On the other hand, the current model seems to be simpler to fit into mind. If a task is not
complete, its files are owned by the job owner, if not, they are owned by TT. It is easy to
check these rules on a running system. So, is it worth the change in approach to bring in
a little optimization (which might actually not matter that much).

h4. 3. Sandboxing task runtime environment by changing values of mapred.local.dir for the

The patch 'sandboxes' the task runtime environment, by changing the mapred.local.dir values
from the original configured values to ${original mapred.local.dir}/taskTracker/jobCache/${job-id}/${task-id}
and pass the new values to the child. Vinod told me that this was primarily required because
checks in the LocalDirAllocator require the current process to have write permissions on the
context passed to it (which is basically the mapred local directories). When the child calls
LocalDirAllocator, it would now fail because the original mapred local directories will not
have write permissions to world. Hence, the need to sandbox. Of course, it is also probably
more secure.

Two questions this raises: Is this change in contract acceptable ? If yes, is it acceptable
in the default case as well, or should it be restricted to the case of LinuxTaskController

Either way, the current patch, in order to implement this behavior juggles around the values
of the mapred.local.dir variable in conf file at 2-3 locations in the tasktracker code. I
think that approach is error prone and needs to change.

Thoughts on these three points ?

> Per-job local data on the TaskTracker node should have right access-control
> ---------------------------------------------------------------------------
>                 Key: HADOOP-4491
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4491
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: security
>            Reporter: Arun C Murthy
>            Assignee: Vinod K V
>         Attachments: HADOOP-4491-20090623-common.1.txt, HADOOP-4491-20090623-mapred.1.txt,
HADOOP-4491-20090703-common.1.txt, HADOOP-4491-20090703-common.txt, HADOOP-4491-20090703.1.txt,
HADOOP-4491-20090703.txt, HADOOP-4491-20090707-common.txt, HADOOP-4491-20090707.txt

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message