-
Bug
-
Resolution: Fixed
-
Major
-
Jenkins 1.651.2
Any Authorization plugin like Project-Based Matrix
If a default value is specified for a Password Parameter in a job, Jenkins is only able to use the default value when the user executing the job is has Configure rights to the job. If the user has only build access, Jenkins will not fail to use the default value and instead send "****"'.
Steps to reproduce:
- Create a job in 1.651.2 with a Password Parameter that has a default value.
- Execute the job as a user who does not have Configure access to the job (maybe Read or Extended Read).
- try to echo the parameter's value or save it to file
- Jenkins will send **** instead of the actual value
This occurs without using Mask Password Plugin, meaning Jenkins is not masking the password but actually sending **** as the value.
I believe that Jenkins is not able to properly extract the default password from Secret because of SECURITY-266
"Users with extended read access could access encrypted secrets stored directly in the configuration of those items."
Note that people upgrading from 1.642 with already configured password parameter jobs will have issues upgrading to 1.651
- links to
I think the problem is that PasswordParameterDefinition/index.jelly uses f:password, which blocks passwords for users lacking Item.CONFIGURE as part of the fix of SECURITY-266. But that defense was intended for form fragments shown in a job configuration screen. When you define a PasswordParameterDefinition.defaultValue, you actually expect that the secret will be exposed to anyone with Item.BUILD. Or perhaps you do not necessarily wish to show them the secret, but wish them to be allowed to use it in the context of a build.