Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.21.0
    • Component/s: security
    • Labels:
      None
    • Hadoop Flags:
      Incompatible change, Reviewed
    • Release Note:
      Hide
      Added job-level authorization to MapReduce. JobTracker will now use the cluster configuration "mapreduce.cluster.job-authorization-enabled" to enable the checks to verify the authority of access of jobs where ever needed. Introduced two job-configuration properties to specify ACLs: "mapreduce.job.acl-view-job" and "mapreduce.job.acl-modify-job". For now, RPCs related to job-level counters, task-level counters and tasks' diagnostic information are protected by "mapreduce.job.acl-view-job" ACL. "mapreduce.job.acl-modify-job" protects killing of a job, killing a task of a job, failing a task of a job and setting the priority of a job. Irrespective of the above two ACLs, job-owner, superuser and members of supergroup configured on JobTracker via mapred.permissions.supergroup, can do all the view and modification operations.
      Show
      Added job-level authorization to MapReduce. JobTracker will now use the cluster configuration "mapreduce.cluster.job-authorization-enabled" to enable the checks to verify the authority of access of jobs where ever needed. Introduced two job-configuration properties to specify ACLs: "mapreduce.job.acl-view-job" and "mapreduce.job.acl-modify-job". For now, RPCs related to job-level counters, task-level counters and tasks' diagnostic information are protected by "mapreduce.job.acl-view-job" ACL. "mapreduce.job.acl-modify-job" protects killing of a job, killing a task of a job, failing a task of a job and setting the priority of a job. Irrespective of the above two ACLs, job-owner, superuser and members of supergroup configured on JobTracker via mapred.permissions.supergroup, can do all the view and modification operations.

      Description

      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.

      1. MAPREDUCE-1307-20100227-ydist.txt
        57 kB
        Vinod Kumar Vavilapalli
      2. MAPREDUCE-1307-20100226.1-ydist.txt
        57 kB
        Vinod Kumar Vavilapalli
      3. MAPREDUCE-1307-20100217.txt
        60 kB
        Vinod Kumar Vavilapalli
      4. MAPREDUCE-1307-20100215.txt
        39 kB
        Vinod Kumar Vavilapalli
      5. MAPREDUCE-1307-20100211.txt
        36 kB
        Vinod Kumar Vavilapalli
      6. MAPREDUCE-1307-20100210.txt
        35 kB
        Vinod Kumar Vavilapalli
      7. 1307-early-1.patch
        13 kB
        Devaraj Das

        Issue Links

          Activity

          Hide
          Hemanth Yamijala added a comment -

          There is a related notion of ACLs for queues which controls who can "modify" - kill, change priorities of jobs in a queue. We may need to scope the interplay between the two.

          Show
          Hemanth Yamijala added a comment - There is a related notion of ACLs for queues which controls who can "modify" - kill, change priorities of jobs in a queue. We may need to scope the interplay between the two.
          Hide
          Hemanth Yamijala added a comment -

          Maybe there's a simple model: queues = directories, jobs = files ? Just thinking aloud.

          Show
          Hemanth Yamijala added a comment - Maybe there's a simple model: queues = directories, jobs = files ? Just thinking aloud.
          Hide
          Devaraj Das added a comment -

          Attaching a rough draft of what i am thinking of.
          1) Introduced mapreduce.job.permission and mapreduce.job.group config options using which users can define (octal) permissions for their job and what groups can perform actions on the job. Only READ & WRITE bits are considered for enforcing permissions. The execute bit of permissions is ignored,
          2) Introduced a new class JobPermission that wraps a FsPermission (a very thin wrapper). All operations are delegated to the FsPermission object.
          All command line operations that try to do some job operation (like kill, etc.) should be covered by this patch..

          Thoughts?

          Show
          Devaraj Das added a comment - Attaching a rough draft of what i am thinking of. 1) Introduced mapreduce.job.permission and mapreduce.job.group config options using which users can define (octal) permissions for their job and what groups can perform actions on the job. Only READ & WRITE bits are considered for enforcing permissions. The execute bit of permissions is ignored, 2) Introduced a new class JobPermission that wraps a FsPermission (a very thin wrapper). All operations are delegated to the FsPermission object. All command line operations that try to do some job operation (like kill, etc.) should be covered by this patch.. Thoughts?
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Why have a separate setup of access control besides the one that JT already inherits from its own filesystem? This I mention, because elsewhere (MAPREDUCE-744), we used the JT filesystem's user/group permissions to see if jobs of multiple users can share localization of distributed-cache files (on the TTs). Definitely, these two should be reconciled, no?

          Show
          Vinod Kumar Vavilapalli added a comment - Why have a separate setup of access control besides the one that JT already inherits from its own filesystem? This I mention, because elsewhere ( MAPREDUCE-744 ), we used the JT filesystem's user/group permissions to see if jobs of multiple users can share localization of distributed-cache files (on the TTs). Definitely, these two should be reconciled, no?
          Hide
          Devaraj Das added a comment -

          The default group for the jobs could definitely be the one that the JobTracker thinks about the user's group. I take the point that the mapreduce.job.group default value could be the job owner's default groups. Is that what you are hinting at?

          Show
          Devaraj Das added a comment - The default group for the jobs could definitely be the one that the JobTracker thinks about the user's group. I take the point that the mapreduce.job.group default value could be the job owner's default groups. Is that what you are hinting at?
          Hide
          Devaraj Das added a comment -

          Another way to look at this is it was much more difficult to enforce group level permissions in mr-744 but enforcing group level permissions for jobs turns out to be simpler and easy to comprehend. In some sense mr-744 is more strict about who can access distributed cache files.

          Show
          Devaraj Das added a comment - Another way to look at this is it was much more difficult to enforce group level permissions in mr-744 but enforcing group level permissions for jobs turns out to be simpler and easy to comprehend. In some sense mr-744 is more strict about who can access distributed cache files.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          My point is not just limited to the default value. At present, users can set arbitrary group ownership for their files on HDFS while JT gets groups details from the machine's own group database. And these two can differ.

          In any case this groups related conflict will only arise once we start fixing MAPREDUCE-1288 to let a group of users share Distcache files. May be I spoke too soon.

          Show
          Vinod Kumar Vavilapalli added a comment - My point is not just limited to the default value. At present, users can set arbitrary group ownership for their files on HDFS while JT gets groups details from the machine's own group database. And these two can differ. In any case this groups related conflict will only arise once we start fixing MAPREDUCE-1288 to let a group of users share Distcache files. May be I spoke too soon.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          I wish to take this issue forward. First, let me summarize this:

          At present, we only have ACLs for queues:

          Queue:

          • submit-job-acl
            • determines which users and/or groups can submit a job to this queue
          • administer-job-acl
            • determines which users and/or groups can perform administration operations like killing, setting priority on a given job
            • the job-owner is always part of this list.

          Now we also want to add authorization per job.

          1307-early-1.patch proposal:

          Queue:

          • same as above using ACLs.

          Job: POSIX file system permissions like model

          • Specifies the jobs's user_owner , group_owner and the permissions
          • user_owner of the job is from authentication
          • group_owner of the job is from job's configuration during submission
          • user_owner can always do all the operations on the job
          • Permissions(RW:RW) specify the rights to group_owner:others respectively
            • R means 'readability' of the job. Meaning whether or not the group/others can view information about the job
            • W means 'writability' of the job. Meaning whether or not the group/others can modify job information, kill job, kill a task of the job, set job-priority etc.
          Show
          Vinod Kumar Vavilapalli added a comment - I wish to take this issue forward. First, let me summarize this: At present, we only have ACLs for queues: Queue : submit-job-acl determines which users and/or groups can submit a job to this queue administer-job-acl determines which users and/or groups can perform administration operations like killing, setting priority on a given job the job-owner is always part of this list. Now we also want to add authorization per job. 1307-early-1.patch proposal: Queue : same as above using ACLs. Job : POSIX file system permissions like model Specifies the jobs's user_owner , group_owner and the permissions user_owner of the job is from authentication group_owner of the job is from job's configuration during submission user_owner can always do all the operations on the job Permissions(RW:RW) specify the rights to group_owner:others respectively R means 'readability' of the job. Meaning whether or not the group/others can view information about the job W means 'writability' of the job. Meaning whether or not the group/others can modify job information, kill job, kill a task of the job, set job-priority etc.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          The above proposal has some idiosyncrasies and can be improved:

          • The permissions model is not uniform across jobs and queues. Jobs use POSIX model while queues use ACLs. Having the same model can simplify the code a bit at the same time, users/admins can use the same model to describe permissions.
          • Job permissions don't strictly follow the POSIX model
            • executable bit will be ignored completely and has no meaning
            • a job can be owned by multiple groups whereas a file can only be owned by a single group
            • because permissions on queues(directories) are still expressed as ACLs, it is not possible to extend the job-permissions to say, implement chmod on the job. The patch currently assumes that the permissions cannot be changed after submission, but this assumption can change in the future.
            • It is difficult to extend the permissions in general too - every operation has to be (forcibly) baked into either the readability or the writability category.

          So, I propose we change the job-permissions also to use ACLs. The only downside is that we lose the simple way of configuring job-permissions using octal numbers, but I think that's OK because even now queues ARE being described in terms of ACLs.

          Thoughts?

          Show
          Vinod Kumar Vavilapalli added a comment - The above proposal has some idiosyncrasies and can be improved: The permissions model is not uniform across jobs and queues. Jobs use POSIX model while queues use ACLs. Having the same model can simplify the code a bit at the same time, users/admins can use the same model to describe permissions. Job permissions don't strictly follow the POSIX model executable bit will be ignored completely and has no meaning a job can be owned by multiple groups whereas a file can only be owned by a single group because permissions on queues(directories) are still expressed as ACLs, it is not possible to extend the job-permissions to say, implement chmod on the job. The patch currently assumes that the permissions cannot be changed after submission, but this assumption can change in the future. It is difficult to extend the permissions in general too - every operation has to be (forcibly) baked into either the readability or the writability category. So, I propose we change the job-permissions also to use ACLs. The only downside is that we lose the simple way of configuring job-permissions using octal numbers, but I think that's OK because even now queues ARE being described in terms of ACLs. Thoughts?
          Hide
          Hemanth Yamijala added a comment -

          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.

          Show
          Hemanth Yamijala added a comment - 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.
          Hide
          Arun C Murthy added a comment -

          I agree that trying to retrofit the file-system model might be tedious, though it is tempting. So, I'm a little uncomfortable going down that path...

          Just curious, what do other systems use for similar purposes? Condor? Torque?

          Show
          Arun C Murthy added a comment - I agree that trying to retrofit the file-system model might be tedious, though it is tempting. So, I'm a little uncomfortable going down that path... Just curious, what do other systems use for similar purposes? Condor? Torque?
          Hide
          Devaraj Das added a comment -

          The advantage with the file-system model is that it is really simple and would handle almost all cases that we might come across. The ACL model is also fine though it is tedious to specify that and pass it to the JobTracker. But it is good to look at the long term... So in that sense, I am tending to agree with Hemanth/Vinod.
          W.r.t condor, torque, i don't think that they have job level read/write permissions model. They are more concerned with the queue operations. But it is something that could be checked.

          Show
          Devaraj Das added a comment - The advantage with the file-system model is that it is really simple and would handle almost all cases that we might come across. The ACL model is also fine though it is tedious to specify that and pass it to the JobTracker. But it is good to look at the long term... So in that sense, I am tending to agree with Hemanth/Vinod. W.r.t condor, torque, i don't think that they have job level read/write permissions model. They are more concerned with the queue operations. But it is something that could be checked.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Torque only has queue ACLs. Users can query other user's jobs based upon a global "query_other_jobs" flag. Condor also doesn't seem to have authorization checks at the fine-grained job-level.

          Show
          Vinod Kumar Vavilapalli added a comment - Torque only has queue ACLs. Users can query other user's jobs based upon a global "query_other_jobs" flag. Condor also doesn't seem to have authorization checks at the fine-grained job-level.
          Hide
          Allen Wittenauer added a comment -

          It may be worthwhile looking to see what IEEE-xxxx that defines the typical job submission system says. Off the top, I think it ignores the security aspect completely.

          Show
          Allen Wittenauer added a comment - It may be worthwhile looking to see what IEEE-xxxx that defines the typical job submission system says. Off the top, I think it ignores the security aspect completely.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          OK.. I am going ahead with ACLs for job permissions. Here's the proposal:

          Users can interact with their jobs via mapred commands, JT RPCs, JT web UI and TT web UI. This issue only handles the authorization of RPCs and hence the command-line clients. Authorization for web UI will be addressed by MAPREDUCE-1455.

          Per-job ACLs can be set by job in JobConf during the submission.

          • As of now, we will only have two per-job ACLs
            • mapreduce.job.acl-modify-job
            • mapreduce.job.acl-view-job
          • Job owner has the authorization to do anything with the job irrespective of the configured ACLs.
          • superuser(the user who starts the mapred cluster) and members of supergroup(configured on JT via mapred.permissions.supergroup) have the authorization to do anything with the job irrespective of the configured ACLs.

          mapreduce.job.acl-modify-job

          • This guards all the modifications w.r.t a job. This takes care of all the following operations that come under this category:
            • killing a job
            • killing a task of a job, failing a task of a job
            • setting the priority of a job
          • Each of these operations are also guarded by the per-queue level ACL "acl-administer-jobs". So a caller(other than the job-owner and the superuser/supergroup) should have the authorization to satisfy both the queue-level ACL and then the job-level ACL.

          mapreduce.job.acl-view-job

          • This guards some of the job-views
          • For now, we only protect APIs that can return possibly sensitive information of the job-owner
            • job-level counters
            • task-level counters
            • task-logs displayed by TT UI and
            • job.xml showed by JT UI
              (The last twowill be handled by MAPREDUCE-1455).
          • The above means every other piece information of jobs is still accessible by any other user, for e.g., JobStatus, JobProfile, list of jobs in the queue, etc.
          Show
          Vinod Kumar Vavilapalli added a comment - OK.. I am going ahead with ACLs for job permissions. Here's the proposal: Users can interact with their jobs via mapred commands, JT RPCs, JT web UI and TT web UI. This issue only handles the authorization of RPCs and hence the command-line clients. Authorization for web UI will be addressed by MAPREDUCE-1455 . Per-job ACLs can be set by job in JobConf during the submission. As of now, we will only have two per-job ACLs mapreduce.job.acl-modify-job mapreduce.job.acl-view-job Job owner has the authorization to do anything with the job irrespective of the configured ACLs. superuser(the user who starts the mapred cluster) and members of supergroup(configured on JT via mapred.permissions.supergroup) have the authorization to do anything with the job irrespective of the configured ACLs. mapreduce.job.acl-modify-job This guards all the modifications w.r.t a job. This takes care of all the following operations that come under this category: killing a job killing a task of a job, failing a task of a job setting the priority of a job Each of these operations are also guarded by the per-queue level ACL "acl-administer-jobs". So a caller(other than the job-owner and the superuser/supergroup) should have the authorization to satisfy both the queue-level ACL and then the job-level ACL. mapreduce.job.acl-view-job This guards some of the job-views For now, we only protect APIs that can return possibly sensitive information of the job-owner job-level counters task-level counters task-logs displayed by TT UI and job.xml showed by JT UI (The last twowill be handled by MAPREDUCE-1455 ). The above means every other piece information of jobs is still accessible by any other user, for e.g., JobStatus, JobProfile, list of jobs in the queue, etc.
          Hide
          dhruba borthakur added a comment -

          > The advantage with the file-system model is that it is really simple and would handle almost all cases that we might come across.

          can somebody please explain why we are abandoning the file-system permission model, and going towards ACLs. Is there a particular use-case that the fs permission model does not address?

          Show
          dhruba borthakur added a comment - > The advantage with the file-system model is that it is really simple and would handle almost all cases that we might come across. can somebody please explain why we are abandoning the file-system permission model, and going towards ACLs. Is there a particular use-case that the fs permission model does not address?
          Hide
          Devaraj Das added a comment -

          Dhruba, the FS permission doesn't support some use cases as Hemanth outlined in his last comment. While I don't think that those are likely cases, I also think that it makes sense to do something that doesn't tie us to the FS permission model. Should we later discover that we have to move to the ACL model to support some use case, it would be a difficult switch and painful for users..

          Show
          Devaraj Das added a comment - Dhruba, the FS permission doesn't support some use cases as Hemanth outlined in his last comment. While I don't think that those are likely cases, I also think that it makes sense to do something that doesn't tie us to the FS permission model. Should we later discover that we have to move to the ACL model to support some use case, it would be a difficult switch and painful for users..
          Hide
          Vinod Kumar Vavilapalli added a comment -

          I am attaching a patch that implements my proposal.

          • The authorization checks can be enabled/disabled by "hadoop.security.authorization" and are switched off by default.
          • When authorization is enabled, the default ACLs don't grant access to anyone except the job-owner and superuser/supergroup.
          • Also added tests for the APIs that need authorization - all the modification operations described above, and for getJobCounters() and getTaskReports() on the view-part.
          Show
          Vinod Kumar Vavilapalli added a comment - I am attaching a patch that implements my proposal. The authorization checks can be enabled/disabled by "hadoop.security.authorization" and are switched off by default. When authorization is enabled, the default ACLs don't grant access to anyone except the job-owner and superuser/supergroup. Also added tests for the APIs that need authorization - all the modification operations described above, and for getJobCounters() and getTaskReports() on the view-part.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Updated patch that fixes client side to print nice message in case of unauthorized access.

          NOTE: CompletedJobStore needs to be fixed w.r.t authorization. This might involve serializing the ACLs to the job-store on DFS and using the same for authorizing further requests. I'll do it as part of a follow-up issue.

          Show
          Vinod Kumar Vavilapalli added a comment - Updated patch that fixes client side to print nice message in case of unauthorized access. NOTE: CompletedJobStore needs to be fixed w.r.t authorization. This might involve serializing the ACLs to the job-store on DFS and using the same for authorizing further requests. I'll do it as part of a follow-up issue.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12435562/MAPREDUCE-1307-20100211.txt
          against trunk revision 908321.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 5 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed core unit tests.

          -1 contrib tests. The patch failed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/446/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/446/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/446/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/446/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12435562/MAPREDUCE-1307-20100211.txt against trunk revision 908321. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 5 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. -1 contrib tests. The patch failed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/446/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/446/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/446/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/446/console This message is automatically generated.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Updated patch fixing tests and adding mapreduce.cluster.job-authorization-enabled.

          Show
          Vinod Kumar Vavilapalli added a comment - Updated patch fixing tests and adding mapreduce.cluster.job-authorization-enabled.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12435845/MAPREDUCE-1307-20100215.txt
          against trunk revision 909993.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 8 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/323/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/323/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/323/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/323/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12435845/MAPREDUCE-1307-20100215.txt against trunk revision 909993. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 8 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/323/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/323/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/323/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h3.grid.sp2.yahoo.net/323/console This message is automatically generated.
          Hide
          Devaraj Das added a comment -

          Looks good overall. There seems to be an unintentional change in JobContext.java (to do with JOB_TOKEN_FILE).

          Show
          Devaraj Das added a comment - Looks good overall. There seems to be an unintentional change in JobContext.java (to do with JOB_TOKEN_FILE).
          Hide
          Devaraj Das added a comment -

          Some comments summarizing an offline discussion with Vinod:
          1) Protect getTaskDiagnostics() APIs also w.r.t access control.
          2) ACLs for jobs should be displayed as part of jobdetails (the front page for jobs where all high level info is displayed).
          3) If a user gets an access control error, he should be informed about the configured ACLs for the job.
          4) Make the ACL part of the JobStatus object so that it is visible to all interested parties who might be interested (including the command line to get the job status). Also, the CompletedJobStatusStore can make use of this and enforce access control..
          5) Can we have the default ACL for job view enabled for the groups the user belongs to? Current patch makes the default to be '', meaning no one else except job-owner and superuser/supergroup can see others' jobs if mapreduce.cluster.job-authorization-enabled is set to true.

          Show
          Devaraj Das added a comment - Some comments summarizing an offline discussion with Vinod: 1) Protect getTaskDiagnostics() APIs also w.r.t access control. 2) ACLs for jobs should be displayed as part of jobdetails (the front page for jobs where all high level info is displayed). 3) If a user gets an access control error, he should be informed about the configured ACLs for the job. 4) Make the ACL part of the JobStatus object so that it is visible to all interested parties who might be interested (including the command line to get the job status). Also, the CompletedJobStatusStore can make use of this and enforce access control.. 5) Can we have the default ACL for job view enabled for the groups the user belongs to? Current patch makes the default to be '', meaning no one else except job-owner and superuser/supergroup can see others' jobs if mapreduce.cluster.job-authorization-enabled is set to true.
          Hide
          Vinod Kumar Vavilapalli added a comment -
          • Protect getTaskDiagnostics() APIs also w.r.t access control.
          • If a user gets an access control error, he should be informed about the configured ACLs for the job.
          • Make the ACL part of the JobStatus object so that it is visible to all interested parties who might be interested (including the command line to get the job status). Also, the CompletedJobStatusStore can make use of this and enforce access control..

          Done

          ACLs for jobs should be displayed as part of jobdetails (the front page for jobs where all high level info is displayed).

          This will be done as part of MAPREDUCE-1455.

          Can we have the default ACL for job view enabled for the groups the user belongs to?

          This is difficult to do without introducing SPECIAL case values ACLs, which itself is tricky and I'm postponing for future as per need.

          Leaving that aside, other changes in the patch include:

          • CompletedJobStore is fixed now to respect ACLs. And because of the new JobStatus objects, JT cannot read JobStatus by previous versions of JT, and hence this is an incompatible change.
          • Refactored the ACLs related methods into a new class JobACLsManager which acts as an interface between JT and any component that needs job-level authorization.
          • JobStatus is modified to include ACLs. ClientProtocol's version is bumped up too - another incompatible change.
          • Added tests to verify the changes in CompletedJobStore.
          Show
          Vinod Kumar Vavilapalli added a comment - Protect getTaskDiagnostics() APIs also w.r.t access control. If a user gets an access control error, he should be informed about the configured ACLs for the job. Make the ACL part of the JobStatus object so that it is visible to all interested parties who might be interested (including the command line to get the job status). Also, the CompletedJobStatusStore can make use of this and enforce access control.. Done ACLs for jobs should be displayed as part of jobdetails (the front page for jobs where all high level info is displayed). This will be done as part of MAPREDUCE-1455 . Can we have the default ACL for job view enabled for the groups the user belongs to? This is difficult to do without introducing SPECIAL case values ACLs, which itself is tricky and I'm postponing for future as per need. Leaving that aside, other changes in the patch include: CompletedJobStore is fixed now to respect ACLs. And because of the new JobStatus objects, JT cannot read JobStatus by previous versions of JT, and hence this is an incompatible change. Refactored the ACLs related methods into a new class JobACLsManager which acts as an interface between JT and any component that needs job-level authorization. JobStatus is modified to include ACLs. ClientProtocol's version is bumped up too - another incompatible change. Added tests to verify the changes in CompletedJobStore.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12436118/MAPREDUCE-1307-20100217.txt
          against trunk revision 910774.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 11 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed core unit tests.

          -1 contrib tests. The patch failed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/459/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/459/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/459/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/459/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12436118/MAPREDUCE-1307-20100217.txt against trunk revision 910774. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 11 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. -1 contrib tests. The patch failed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/459/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/459/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/459/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/459/console This message is automatically generated.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          TestJobRetire failed by Hudson is passing locally. Let me rerun the patch through Hudson.

          Show
          Vinod Kumar Vavilapalli added a comment - TestJobRetire failed by Hudson is passing locally. Let me rerun the patch through Hudson.
          Hide
          Amareshwari Sriramadasu added a comment -

          I looked at the console output for TestJobRetire. The timeout is because of HADOOP-6528.
          Corresponding console log:

               [exec]     [junit] 2010-02-17 19:43:41,099 ERROR mapred.TaskTracker (TaskTracker.java:offerService(1430)) - Caught exception: java.io.IOException: Jetty problem. Jetty didn't bind to a valid port
               [exec]     [junit] 	at org.apache.hadoop.mapred.TaskTracker.checkJettyPort(TaskTracker.java:1246)
               [exec]     [junit] 	at org.apache.hadoop.mapred.TaskTracker.offerService(TaskTracker.java:1408)
               [exec]     [junit] 	at org.apache.hadoop.mapred.TaskTracker.run(TaskTracker.java:2226)
               [exec]     [junit] 	at org.apache.hadoop.mapred.MiniMRCluster$TaskTrackerRunner.run(MiniMRCluster.java:228)
               [exec]     [junit] 	at java.lang.Thread.run(Thread.java:619)
               [exec]     [junit] 
               [exec]     [junit] 2010-02-17 19:43:41,100 INFO  util.AsyncDiskService (AsyncDiskService.java:shutdown(107)) - Shutting down all AsyncDiskService threads...
               [exec]     [junit] 2010-02-17 19:43:41,100 INFO  util.AsyncDiskService (AsyncDiskService.java:awaitTermination(136)) - All AsyncDiskService threads are terminated.
               [exec]     [junit] 2010-02-17 19:43:41,100 INFO  mapred.TaskTracker (TaskTracker.java:run(792)) - Shutting down: Map-events fetcher for all reduce tasks on tracker_host0.foo.com:localhost/127.0.0.1:38229
          
          Show
          Amareshwari Sriramadasu added a comment - I looked at the console output for TestJobRetire. The timeout is because of HADOOP-6528 . Corresponding console log: [exec] [junit] 2010-02-17 19:43:41,099 ERROR mapred.TaskTracker (TaskTracker.java:offerService(1430)) - Caught exception: java.io.IOException: Jetty problem. Jetty didn't bind to a valid port [exec] [junit] at org.apache.hadoop.mapred.TaskTracker.checkJettyPort(TaskTracker.java:1246) [exec] [junit] at org.apache.hadoop.mapred.TaskTracker.offerService(TaskTracker.java:1408) [exec] [junit] at org.apache.hadoop.mapred.TaskTracker.run(TaskTracker.java:2226) [exec] [junit] at org.apache.hadoop.mapred.MiniMRCluster$TaskTrackerRunner.run(MiniMRCluster.java:228) [exec] [junit] at java.lang.Thread.run(Thread.java:619) [exec] [junit] [exec] [junit] 2010-02-17 19:43:41,100 INFO util.AsyncDiskService (AsyncDiskService.java:shutdown(107)) - Shutting down all AsyncDiskService threads... [exec] [junit] 2010-02-17 19:43:41,100 INFO util.AsyncDiskService (AsyncDiskService.java:awaitTermination(136)) - All AsyncDiskService threads are terminated. [exec] [junit] 2010-02-17 19:43:41,100 INFO mapred.TaskTracker (TaskTracker.java:run(792)) - Shutting down: Map-events fetcher for all reduce tasks on tracker_host0.foo.com:localhost/127.0.0.1:38229
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12436118/MAPREDUCE-1307-20100217.txt
          against trunk revision 911519.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 11 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/464/testReport/
          Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/464/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/464/artifact/trunk/build/test/checkstyle-errors.html
          Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/464/console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12436118/MAPREDUCE-1307-20100217.txt against trunk revision 911519. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 11 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/464/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/464/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/464/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Mapreduce-Patch-h6.grid.sp2.yahoo.net/464/console This message is automatically generated.
          Hide
          Devaraj Das added a comment -

          +1

          Show
          Devaraj Das added a comment - +1
          Hide
          Devaraj Das added a comment -

          I just committed this. Thanks, Vinod!

          Show
          Devaraj Das added a comment - I just committed this. Thanks, Vinod!
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Patch for previous versions of the repo. Not for commit here.

          Show
          Vinod Kumar Vavilapalli added a comment - Patch for previous versions of the repo. Not for commit here.
          Hide
          Vinod Kumar Vavilapalli added a comment -

          Updated patch for previous versions.

          Show
          Vinod Kumar Vavilapalli added a comment - Updated patch for previous versions.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk-Commit #252 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Mapreduce-trunk-Commit/252/)

          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk-Commit #252 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Mapreduce-trunk-Commit/252/ )
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk #248 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Mapreduce-trunk/248/)

          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk #248 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Mapreduce-trunk/248/ )

            People

            • Assignee:
              Vinod Kumar Vavilapalli
              Reporter:
              Devaraj Das
            • Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development