[
https://issues.apache.org/jira/browse/MAPREDUCE-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830671#action_12830671
]
Hemanth Yamijala commented on MAPREDUCE-1307:
---------------------------------------------
For queues, the flexibility of ACLs seems required. Since queues can be setup
for solving different use-cases - for e.g. all small jobs to a queue - one can
imagine that an arbitrary set of users / groups need to be granted access. It
is difficult to setup POSIX style permissions to solve such access
requirements. Hence ACLs.
For jobs, I am not that certain if a POSIX model is insufficient. For e.g.
would we need arbitrary user / group access to jobs ? While it seems unlikely,
it is equally possible to construct a use case where this would be useful. For
example, say a department in an organization is submitting jobs to a shared
grid. Say the grid already has a group of administrators who manage all
resources of the grid. We probably would want 'write' access to the jobs given
to the grid admins, an operator group of the department, and the job submitter.
This seems to imply different groups would need access to the jobs - something
that cannot be setup in a plain POSIX model.
Given this, I think it may be safer to model job permissions using a flexible
ACL model as for queues. So I am +1 for Vinod's proposal.
> Introduce the concept of Job Permissions
> ----------------------------------------
>
> Key: MAPREDUCE-1307
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-1307
> Project: Hadoop Map/Reduce
> Issue Type: Sub-task
> Components: security
> Reporter: Devaraj Das
> Fix For: 0.22.0
>
> Attachments: 1307-early-1.patch
>
>
> It would be good to define the notion of job permissions analogous to file
> permissions. Then the JobTracker can restrict who can "read" (e.g. look at
> the job page) or "modify" (e.g. kill) jobs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
