-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins 2.222.3
Authorize Project 1.3.0
ownership-plugin 0.12.1
Context
Currently we have defined the Authorize Project to use the following order to identify the user to run a job as:
- Configuration defined at the level of the job
- Run as "any developer" (limited role basically)
I wanted to introduce an intermediary step "Run as owner".
The issue here is that the ownership plugin doesn't check if ownership is defined and returns "Anonymous" if one of the following conditions is true
- Ownership is disabled
- There is no primary owner defined
While I'm not too sure about the latter, I'm pretty sure that the former is causing us an issue: on most of projects owners are not defined... And thus our jobs get to run as "Anonymous" ... Which obviously means it doesn't run !
Acceptance criteria
- If ownership is disabled the "Run as owner" should basically be identified as "nothing defined" and Authorize project should proceed to the next policy.
[JENKINS-62184] Ownership based authorization preventing fallback authorizations from kicking in
It might be possible to fix it in a compatible way just by adding explicit fallback policy definition. W.r.t. breaking changes, I am open to consider them. I will likely have to do a major release soon anyway (Jenkins core dependency issues)
> Indeed: if I fix this the way I thought it should be (e.g. by returning null if ownership is not defined), then, in cases where no fallback policy is defined a default one would be returned which would be system, instead of anonymous.
This is not exactly how Queue Item Authentication works in Jenkins. If Authorize Project is enabled on the instance, Jenkins falls back to "anonymous" if authorization strategy does not provide value. So the plugin's behavior is aligned with what the Jenkins core does.
Looking at the code it seems that this issue would not be "that easy" to fix without introducing a breaking change.
Indeed: if I fix this the way I thought it should be (e.g. by returning null if ownership is not defined), then, in cases where no fallback policy is defined a default one would be returned which would be system, instead of anonymous.
To me this would make sense, though, but I'm no expert on this matter (I started playing with this plugin a few weeks ago so I cannot be considered as a "guru" here
).
If the option I saw is seen as acceptable, I would be glad to make the corresponding PR (with unit tests and so on).