Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-13502

Editing any job removes inaccessible downstream jobs from all accessible jobs

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • 1.460 on Windows 7

      If a user is editing any job, all jobs accessible to that user lose their downstream build triggers to jobs that are inaccessible to the editing user.

      Example:
      1. Jenkins is using a project-based security model (e.g. project-based matrix or role strategy plugin)
      2. There are two users, Admin (full access) and User (restricted access).
      3. There are three jobs, U (upstream), D (downstream), and E (edit).
      4. Give User read-only access to job U and read/config access to job E. Give User no permissions for job D.
      5. Admin adds a downstream build of job D to job U. This association is invisible to user U1 despite read access to job U.
      6. User edits job E

      Expected result
      Job U is not affected.

      Actual result
      The build trigger of job D is removed from job U despite User neither having editing permissions to that job, nor actually accessing that job.

      Workarounds
      Use parameterized build trigger and check [x] trigger without parameters

      Notes

      • Something similar would probably happen when User is editing job U despite nobody expecting removal of the invisible association, but there's at least some connection between User's action and the removal of the association.
      • Classified as blocker, since this issue is difficult to track down (even with e.g. job config history plugin), bypasses Jenkins security, and can break a lot of job upstream/downstream associations for no apparent reason.

          [JENKINS-13502] Editing any job removes inaccessible downstream jobs from all accessible jobs

          Daniel Beck created issue -
          Daniel Beck made changes -
          Fix Version/s Original: current [ 10162 ]
          Description Original: If a user is editing any job, all jobs accessible to that user lose their downstream build triggers to jobs that are inaccessible to the editing user.

          Example:
          1. Jenkins is using a project-based security model (e.g. project-based matrix or role strategy plugin)
          2. There are two users, Admin (full access) and User (restricted access).
          3. There are three jobs, U (upstream), D (downstream), and E (edit).
          4. Give User read-only access to job U and read/config access to job E. Give User no permissions for job D.
          5. Admin adds a downstream build of job D to job U. This association is invisible to user U1 despite read access to job U.
          6. User edits job E

          Expected result
          Job U is not affected.

          Actual result
          The build trigger of job D is removed from job U despite User neither having editing permissions to that job, nor actually accessing that job.

          Workarounds
          Use parameterized build trigger and check [x] trigger without parameters

          Notes
          * Something similar would probably happen when User is editing job U despite nobody expecting removal of the invisible association, but there's at least *some* connection between User's action and the removal of the association.
          * Classified as blocker, since this issue is difficult to track down (even with e.g. job config history plugin), bypasses Jenkins security, and can break a lot of job upstream/downstream associations.
          New: If a user is editing any job, all jobs accessible to that user lose their downstream build triggers to jobs that are inaccessible to the editing user.

          Example:
          1. Jenkins is using a project-based security model (e.g. project-based matrix or role strategy plugin)
          2. There are two users, Admin (full access) and User (restricted access).
          3. There are three jobs, U (upstream), D (downstream), and E (edit).
          4. Give User read-only access to job U and read/config access to job E. Give User no permissions for job D.
          5. Admin adds a downstream build of job D to job U. This association is invisible to user U1 despite read access to job U.
          6. User edits job E

          Expected result
          Job U is not affected.

          Actual result
          The build trigger of job D is removed from job U despite User neither having editing permissions to that job, nor actually accessing that job.

          Workarounds
          Use parameterized build trigger and check [x] trigger without parameters

          Notes
          * Something similar would probably happen when User is editing job U despite nobody expecting removal of the invisible association, but there's at least *some* connection between User's action and the removal of the association.
          * Classified as blocker, since this issue is difficult to track down (even with e.g. job config history plugin), bypasses Jenkins security, and can break a lot of job upstream/downstream associations for no apparent reason.
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-16956 [ JENKINS-16956 ]
          Nicolas De Loof made changes -
          Assignee New: Nicolas De Loof [ ndeloof ]
          Jesse Glick made changes -
          Jesse Glick made changes -
          Labels New: 1.480.4-candidate security
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          Jesse Glick made changes -
          Labels Original: 1.480.4-candidate security New: lts-candidate security
          vjuranek made changes -
          Labels Original: lts-candidate security New: 1.509.1-fixed security
          Daniel Beck made changes -
          Link New: This issue is related to JENKINS-14992 [ JENKINS-14992 ]
          Jesse Glick made changes -
          Link New: This issue is related to SECURITY-109 [ SECURITY-109 ]

            ndeloof Nicolas De Loof
            danielbeck Daniel Beck
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: