-
Bug
-
Resolution: Fixed
-
Blocker
-
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.
- depends on
-
JENKINS-16956 Require authentication for build triggers
-
- Resolved
-
- is duplicated by
-
JENKINS-12009 Downstream projects links disappeared
-
- Resolved
-
- is related to
-
JENKINS-14992 Can add "build other projects" trigger to a project we cannot otherwise configure
-
- Resolved
-
[JENKINS-13502] Editing any job removes inaccessible downstream jobs from all accessible jobs
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. |
Link |
New:
This issue depends on |
Assignee | New: Nicolas De Loof [ ndeloof ] |
Labels | New: 1.480.4-candidate security |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Labels | Original: 1.480.4-candidate security | New: lts-candidate security |
Labels | Original: lts-candidate security | New: 1.509.1-fixed security |
Link |
New:
This issue is related to |
Link | New: This issue is related to SECURITY-109 [ SECURITY-109 ] |