You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Arun C Murthy (JIRA)" <ji...@apache.org> on 2008/10/22 22:29:44 UTC
[jira] Created: (HADOOP-4491) Per-job local data on the TaskTracker
node should have right access-control
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 Core
Issue Type: Sub-task
Reporter: Arun C Murthy
Assignee: Arun C Murthy
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-4491) Per-job local data on the TaskTracker
node should have right access-control
Posted by "Arun C Murthy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arun C Murthy updated HADOOP-4491:
----------------------------------
Component/s: security
mapred
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
> Assignee: Arun C Murthy
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Vinod K V (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vinod K V reassigned HADOOP-4491:
---------------------------------
Assignee: Vinod K V
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Vinod K V (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716620#action_12716620 ]
Vinod K V commented on HADOOP-4491:
-----------------------------------
I am summarizing the state-of-the-art local data management on TT
*Localization of task on the TT:*
- Job localization
-- happens once per job
-- creates taskTracker/jobcache/jobid, tasktracker/jobcache/jobid/work directories recursively
-- downloads job.xml to taskTracker/jobcache/jobid/job.xml and job jar to tasktracer/jobcache/jobid/jars/job.jar
- Task localization
-- happens once per task
-- creates task's work directory recursively: taskTracker/jobcache/jobid/taskid[.cleanup]/work
-- if needed, localizes archives and files for distributed cache to tasktracker/archive and/or creates symlinks in the task's work directory, and rewrites job.xml
-- creates mapred.child.tmp directory
-- creates hadoop.log.dir|userlogs/taskid/ recursively and marks child to redirect its stdout and stderr to this directory
-- creates taskjvm.sh in case of linux task controller
*Intermediate output files*
- All the intermediate files created by tasks run as user in taskTracker/jobcache/jobid/taskid[.cleanup]/output/ which is recursively created on demand by the child jvm.
*Intermediate output serving*
- TaskTracker directly reads the map-intermediate output files from taskTracker/jobcache/jobid/taskid[.cleanup]/output/ and serves it to reduces via MapOutputServlet
*Task logs' serving*
- Syslogs of tasks are created by the child jvm in hadoop.log.dir|userlogs/taskid as syslog
- TaskTracker directly reads the tasks' logs and serves it via TaskLogServlet
In summary, the current directory structure follows. Unless otherwise stated, directories/files are owned by TT but used by both TT and child.
{noformat}
taskTracker
|- archive
|- jobcache
|- jobid
|- work
|- job.xml
|- jars/job.jar
|- taskid[.cleanup]
|- work
|- taskjvm.sh ( created and used by TT)
|- output ( owned by child, used by TT)
|- all intermediate output files ( owned by child, used by TT)
mapred.child.tmp ( owned and used by child)
hadoop.log.dir|userlogs (owned and used by child)
|- taskid (owned and used by child)
|- stdout ( owned by child, used by TT)
|- stderr ( owned by child, used by TT)
|- syslog ( owned by child, used by TT)
{noformat}
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Kan Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661722#action_12661722 ]
Kan Zhang commented on HADOOP-4491:
-----------------------------------
> It will be interesting to see how we will deal with intermediate data (map output).
I have opened a new JIRA for it. See HADOOP-4991.
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Devaraj Das (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724484#action_12724484 ]
Devaraj Das commented on HADOOP-4491:
-------------------------------------
On the mapreduce part of the patch,
1) TaskTracker.getIntermediateOutputDirForChild can be renamed to getBaseIntermediateOutputDir
2) TaskTracker.initializeJobDirs should delete stuff on all the disks, but should return successfully if it is able to create the path on at least one disk
3) job-id/work should be user owned?
4) Check whether the call to mkdirs(workDir) in localizeJob is required?
5) There is a spurious LOG.info(" From fComf " + fConf.get("mapred.local.dir")); in localizeTask. Remove it.
6) Files created within private directories don't have to have 700 permissions. Remove all such permissions settings (e.g., this applies to localTaskFile in localizeTask)
7) The work-dir in the attempt directory should be readable/writable by all tasks that the JVM runs (in the jvm reuse case). Currently, jvmManager.finalizeTaskDirs will prevent this from happening.
8) It'd be good to remove redundant calls to finalizeTaskDirs in JvmManager.
9) It will be nice to combine the APIs for creating files/directories and setting appropriate permissions all in one API
10) Check if the configuration setting of mapred.local.dir for the child can be done in the TaskTracker before launching the task (instead of the task itself doing that)
11) There is a spurious LOG.info in Child. Remove that or reword that.
I haven't looked at the TaskController/LinuxTaskController changes..
> 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: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
> Attachments: HADOOP-4491-20090623-common.1.txt, HADOOP-4491-20090623-mapred.1.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Vinod K V (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717253#action_12717253 ]
Vinod K V commented on HADOOP-4491:
-----------------------------------
Some (broad) proposals for solving this issue:
*Localization*
(A) Move the whole localization out of the taskTracker o be done as the user.
- Adv: Because everything is done by the user, there is no hassle of changing permission now and then in TT. We just need to support reading of data back by the TT for serving.
- Disadv: (As Devaraj pointed out in a quick chat) Synchronizing localization across the different process becomes quite complicated
(B) Separate tt-only, child-only space from shared space. TT-only and child-only spaces are exclusively for the TT and the child respectively. TT does localization in tt-only area, task-controller binary then moves directory structure to the child only area. The shared space is for the stuff generated by the child for TT and has restricted access (511 on dirs and 444 on files) for TT and others. Even though other users can read this area, they won't be able to delete/write stuff.
- Adv: Keeps things very simple
- DisAdv: Sacrifices some of the stiff 700 acess restrictions in favour of a more manageable 511/444 permissions.
(C) Instead of separating the directory structures completely, use the same for both TT and the user wherever necessary.
- Adv : Avoids replication of the directory structure
- DisAdv: Paths closer to the mapred-local-dir are owned by TT and further down the paths are owned by the child. Currently, task use same mapred.local.dir as task-tracker. When tasks need a path for writing their output, the LocalDirAllocator checks write permission on root directory owned by tt only and would fail We will have to handle this by modifying the mapred-local-dir of the child.
*Intermediate output*
- If we chose (A) or (C) for localization, we need to run the task-controller again to make the output accessible to the TT
- If we chose (B) for localization, intermediate output is automatically available to the TT.
*Task logs*
- If we chose (A) or (C), whenever there is a request for the logs, we need to run the task-controller to run to stream the logs. Logs can be moved to tt-accessible area once task finishes.
- If we chose (C), task-logs can be put in shared space readable by all users, and so are automatically available.
Depending on these, I think that even though (B) sacrifices some of the strict 700 restrictions to a more free 511/444, it keeps things simple. But I am open to other proposals too. Thoughts?
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Devaraj Das (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724066#action_12724066 ]
Devaraj Das commented on HADOOP-4491:
-------------------------------------
On the patch that affects common, some comments:
1) RunJar.unjar should set the permissions for all the entries in the path after expansion
2) DiskChecker.java has lot of code to do with permissions handling to make it generic but not everything would be actually used. In fact, the approach taken in making some APIs generic is debatable. We might as well keep it simple for now and extend those APIs as and when required.
3) LocalDirAllocator.getSecureLocalPathForWrite could be renamed as getPrivateLocalPathForEWrite
> 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: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
> Attachments: HADOOP-4491-20090623-common.1.txt, HADOOP-4491-20090623-mapred.1.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Vinod K V (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725562#action_12725562 ]
Vinod K V commented on HADOOP-4491:
-----------------------------------
Documenting more things that need to be done. These came out in a short discussion with Hemanth/Sreekanth.
- Userlogs should be cleanable by the TT which isn't possible with the last patch as attempt-dirs in userlogs is owned by the user.
- Jvm-reuse doesn't work with the current patch.
> 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: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
> Attachments: HADOOP-4491-20090623-common.1.txt, HADOOP-4491-20090623-mapred.1.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-4491) Per-job local data on the TaskTracker
node should have right access-control
Posted by "Vinod K V (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vinod K V updated HADOOP-4491:
------------------------------
Attachment: HADOOP-4491-20090623-mapred.1.txt
HADOOP-4491-20090623-common.1.txt
Attaching two files - one for common project and one for mapreduce - for review.
> 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: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
> Attachments: HADOOP-4491-20090623-common.1.txt, HADOOP-4491-20090623-mapred.1.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Vinod K V (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716581#action_12716581 ]
Vinod K V commented on HADOOP-4491:
-----------------------------------
Here's an overview of the problem(with most of the input from [~sreekanth]):
*Objective*:
- Setup secure permissions for task files and job files. Secure permissions means permission only to the user running the job (700).
*Problems to solve*:
With HADOOP-4490, framework is in place to run the user's process as the user himself/herself. To continue to run jobs successfully, HADOOP-4490 set permissions of all files to 777. The scope of this issue is o set secure permissions for these files. After setting these,
- we should be able to run jobs successfully as a user different from the TaskTracker user,
- all the files the user owns have to be set 700 permissions,
- TT should continue to be able to serve map intermediate outputs to reduces and serve user-logs via TaskLogServlet.
*Issues involved:*
- handling localization for tasks.
- handling intermediate output files.
- handling intermediate output serving.
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Vinod K V (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723003#action_12723003 ]
Vinod K V commented on HADOOP-4491:
-----------------------------------
Few points:
- After discussing with Hemanth/Sreekanth and looking up the original intentions of HADOOP-4490, I've reworked the above proposal to have very tight(0700) permissions everywhere.
- But to allow multiple users to create paths, the following paths still have 755 permissions: taskTracker, jobcache, job directory, root-log-dir and distribute cache directory.
- We need more work to secure the logs. In these patches, log directories of attempts inside userlogs are owned by the user, but still have 755 permissions fo the TT to read them back to serve via TaskLogServlet.
Here's what the patches do:
common-patch:
- Changes LocalDirAllocator and DiskChecker to changes permissions of the paths created using java api to set permission instead of spawning chmod processes.
mapreduce-patch:
- Changes TaskTracker related classes to create secure paths with 700 permissions by calling LocalDirAllocator.getSecurePathForWrite() instead of the usual LocalDirAllocator.getLocalPathForWrite()
- Splits TaskTracker.getIntermediateOutputDir() into TaskTracker.getIntermediateOutputDirForChild and TaskTracker.getIntermediateOutputDirForTT() as now, child's mapred.local.dir is modified so as to sandbox it for preserving secure permissions.
- Makes changes to LinuxTaskController binary to do the following:
-- Change ownership of attempt-dir, jars-dir, log-dir to be owned by the child at jvm startup.
-- Finalize task-directories to be owned back by the TT when a task finishes for output serving and cleaning up.
-- Finalizing job-dirs to be owned by the TT when the job finishes.
- Adds a new c based testing for the LinuxTaskController and makes relevant changes to the build.xml, MakeFile, configure.ac. This test can be run by the target test-task-controller.
- Modifies tests inheriting from ClusterWithLinuxTaskController to reflect the above changes.
- Incorporates changes needed for MAPREDUCE-131.
I've tested the patch by running the LinuxTaskController specific tests and observing the directory structure over time. All the tests with successful, failed, killed jobs, with and without reuse pass in the sense that throughout a job's timeline, any path is either owned by the TT or the child and has the most secure permissions possible.
> 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: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
> Attachments: HADOOP-4491-20090623-common.1.txt, HADOOP-4491-20090623-mapred.1.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (HADOOP-4491) Per-job local data on
the TaskTracker node should have right access-control
Posted by "Vinod K V (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716620#action_12716620 ]
Vinod K V edited comment on HADOOP-4491 at 6/8/09 5:56 AM:
-----------------------------------------------------------
I am summarizing the state-of-the-art local data management on TT
*Localization of task on the TT:*
- Job localization
-- happens once per job
-- creates taskTracker/jobcache/jobid, tasktracker/jobcache/jobid/work directories recursively
-- downloads job.xml to taskTracker/jobcache/jobid/job.xml and job jar to tasktracer/jobcache/jobid/jars/job.jar
- Task localization
-- happens once per task
-- creates task's work directory recursively: taskTracker/jobcache/jobid/taskid[.cleanup]/work
-- if needed, localizes archives and files for distributed cache to tasktracker/archive and/or creates symlinks in the task's work directory, and rewrites job.xml
-- creates mapred.child.tmp directory
-- creates hadoop.log.dir|userlogs/taskid/ recursively and marks child to redirect its stdout and stderr to this directory
-- creates taskjvm.sh in case of linux task controller
*Intermediate output files*
- All the intermediate files created by tasks run as user in taskTracker/jobcache/jobid/taskid[.cleanup]/output/ which is recursively created on demand by the child jvm.
*Intermediate output serving*
- TaskTracker directly reads the map-intermediate output files from taskTracker/jobcache/jobid/taskid[.cleanup]/output/ and serves it to reduces via MapOutputServlet
*Task logs' serving*
- Syslogs of tasks are created by the child jvm in hadoop.log.dir|userlogs/taskid as syslog
- TaskTracker directly reads the tasks' logs and serves it via TaskLogServlet
In summary, the current directory structure follows. Unless otherwise stated, directories/files are owned by TT but used by both TT and child.
{noformat}
taskTracker
|- archive
|- jobcache
|- jobid
|- work
|- job.xml
|- jars/job.jar
|- taskid[.cleanup]
|- work
|- job.xml / task-specific
|- taskjvm.sh ( created and used by TT)
|- output ( owned by child, used by TT)
|- all intermediate output files ( owned by child, used by TT)
mapred.child.tmp ( owned and used by child)
hadoop.log.dir|userlogs (owned and used by child)
|- taskid (owned and used by child)
|- stdout ( owned by child, used by TT)
|- stderr ( owned by child, used by TT)
|- syslog ( owned by child, used by TT)
{noformat}
was (Author: vinodkv):
I am summarizing the state-of-the-art local data management on TT
*Localization of task on the TT:*
- Job localization
-- happens once per job
-- creates taskTracker/jobcache/jobid, tasktracker/jobcache/jobid/work directories recursively
-- downloads job.xml to taskTracker/jobcache/jobid/job.xml and job jar to tasktracer/jobcache/jobid/jars/job.jar
- Task localization
-- happens once per task
-- creates task's work directory recursively: taskTracker/jobcache/jobid/taskid[.cleanup]/work
-- if needed, localizes archives and files for distributed cache to tasktracker/archive and/or creates symlinks in the task's work directory, and rewrites job.xml
-- creates mapred.child.tmp directory
-- creates hadoop.log.dir|userlogs/taskid/ recursively and marks child to redirect its stdout and stderr to this directory
-- creates taskjvm.sh in case of linux task controller
*Intermediate output files*
- All the intermediate files created by tasks run as user in taskTracker/jobcache/jobid/taskid[.cleanup]/output/ which is recursively created on demand by the child jvm.
*Intermediate output serving*
- TaskTracker directly reads the map-intermediate output files from taskTracker/jobcache/jobid/taskid[.cleanup]/output/ and serves it to reduces via MapOutputServlet
*Task logs' serving*
- Syslogs of tasks are created by the child jvm in hadoop.log.dir|userlogs/taskid as syslog
- TaskTracker directly reads the tasks' logs and serves it via TaskLogServlet
In summary, the current directory structure follows. Unless otherwise stated, directories/files are owned by TT but used by both TT and child.
{noformat}
taskTracker
|- archive
|- jobcache
|- jobid
|- work
|- job.xml
|- jars/job.jar
|- taskid[.cleanup]
|- work
|- taskjvm.sh ( created and used by TT)
|- output ( owned by child, used by TT)
|- all intermediate output files ( owned by child, used by TT)
mapred.child.tmp ( owned and used by child)
hadoop.log.dir|userlogs (owned and used by child)
|- taskid (owned and used by child)
|- stdout ( owned by child, used by TT)
|- stderr ( owned by child, used by TT)
|- syslog ( owned by child, used by TT)
{noformat}
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
> Assignee: Vinod K V
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-4491) Per-job local data on the
TaskTracker node should have right access-control
Posted by "Amar Kamat (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644644#action_12644644 ]
Amar Kamat commented on HADOOP-4491:
------------------------------------
It will be interesting to see how we will deal with intermediate data (map output). Even if we store intermediate data under user's permission, we will still have to open it for shuffle/reduce.
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-4491) Per-job local data on the TaskTracker
node should have right access-control
Posted by "Hemanth Yamijala (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hemanth Yamijala updated HADOOP-4491:
-------------------------------------
Assignee: (was: Arun C Murthy)
> 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 Core
> Issue Type: Sub-task
> Components: mapred, security
> Reporter: Arun C Murthy
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.