[
https://issues.jenkins-ci.org/browse/JENKINS-13502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Beck updated JENKINS-13502:
----------------------------------
Fix Version/s: (was: current)
Description:
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.
was:
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.
> Editing any job removes inaccessible downstream jobs from all accessible jobs
> -----------------------------------------------------------------------------
>
> Key: JENKINS-13502
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13502
> Project: Jenkins
> Issue Type: Bug
> Components: core
> Affects Versions: current
> Environment: 1.460 on Windows 7
> Reporter: Daniel Beck
> Priority: Blocker
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
