-
Bug
-
Resolution: Unresolved
-
Major
-
None
The three components referenced here appear to be participating in an upgrade-hell scenario from which there is no escape. After upgrading to the latest recommended versions (groovy-2.0, ScriptSecuityPlugin-1.34 Role-Based-Auth-Strategy-2.6.0), If you have System groovy scripts in your instance, and are using the role-based security plugin as a user with admin privileges, then running a job that calls a system groovy script fails over and over with errors on each groovy method call. When it fails, going into the In-process Script approval, offers me only the choice of approving a groovy method call, which is NOT what I want to do! Nothing in the UI permits me to do what I DO want to do, that is to approve the whole script. If I approve the groovy method call and attempt to run my job again, then that method call is ok, but the next line of the script produces an error. I suppose I could approve each method call, but that is only making things less secure!
Again, something in the UI should allow me to approve the script and nothing does. Thus all the security fixes are useless to me because I can't install them and run my System groovy scripts.
UPDATE: I've amended this to remove mention of the Role Based Auth Strategy plugin. That appears to have been an unrelated red herring. The issue, as Oleg describes, is simply that when a script file is specified, one is not given the opportunity to approve the whole script but only to approve each method call line-by-line.
[JENKINS-47072] Unable to upgrade Jenkins plugins due to Groovy security
Steve Cohen
added a comment - So this is a bug/feature request on the Groovy plugin? Will someone from that group be looking at this now?
Steve Cohen
added a comment - So this is a bug/feature request on the Groovy plugin? Will someone from that group be looking at this now? Steve Cohen
added a comment - Can I get some answer as to when this issue might be addressed? It's sat here for over two months and other than Oleg Nenashev's suggestion on how to address the issue, there been a total lack of activity.
I don't know what "support a non-sandbox mode for script files" means.
I can't be the only one with this issue. This issue prevents me from installing multiple security upgrades into my instance. Can someone suggest a workaround that does what my script does (see attached) but does not get derailed by this problem, so that I can upgrade my instance?
Steve Cohen
added a comment - Can I get some answer as to when this issue might be addressed? It's sat here for over two months and other than Oleg Nenashev's suggestion on how to address the issue, there been a total lack of activity.
I don't know what "support a non-sandbox mode for script files" means.
I can't be the only one with this issue. This issue prevents me from installing multiple security upgrades into my instance. Can someone suggest a workaround that does what my script does (see attached) but does not get derailed by this problem, so that I can upgrade my instance?
CC olivergondza who has released the last version of the plugin. Probably he is a maintainer now.
> Can I get some answer as to when this issue might be addressed? It's sat here for over two months and other than Oleg Nenashev's suggestion on how to address the issue, there been a total lack of activity.
Jenkins is a community-driven open-source project, we do not define any SLA. The issue may be open for years if the submitter is not interested to study the code and to fix that && if there is no active maintainer. We welcome all people who are interested to contribute.
Also CC danielbeck who *may* want to prioritize this fix in the Jenkins Security Team.
The workaround is to define scripts inline in Jenkins (first radio button), and approve as a whole script.
Scripts from workspace are potentially from untrusted sources, so only support sandboxed mode (similar to Jenkinsfiles from SCM in Pipeline).
Steve Cohen
added a comment - There is possibly a deeper issue here. While waiting for the above replies, and thank you, Oleg and Daniel, for them, I once again tried installing the new ScriptApproval and Groovy plugins. The same issue still occurs (I have not yet tried Daniel's suggestion of putting the script inline). However, the wrinkle I find is that even after approving the method call:
and then running Job again, the same error occurs even though I am running the job as an adminstrative user. Is there something special about this method that resists being allowed? After reading something somewhere, I also tried modifying my script to call Jenkins.getInstance() directly rather than the code shown in the above attachment that called Jenkins.instance. None of these things helped.
Steve Cohen
added a comment - There is possibly a deeper issue here. While waiting for the above replies, and thank you, Oleg and Daniel, for them, I once again tried installing the new ScriptApproval and Groovy plugins. The same issue still occurs (I have not yet tried Daniel's suggestion of putting the script inline). However, the wrinkle I find is that even after approving the method call:
and then running Job again, the same error occurs even though I am running the job as an adminstrative user. Is there something special about this method that resists being allowed? After reading something somewhere, I also tried modifying my script to call Jenkins.getInstance() directly rather than the code shown in the above attachment that called Jenkins.instance. None of these things helped.
It does appear that putting the script online gets me over this hump, so Daniel's workaround appears good. But I was not even asked to approve the script, it was simply accepted. Was this because the system knew I was an administrative user?
Steve Cohen
added a comment - - edited It does appear that putting the script online gets me over this hump, so Daniel's workaround appears good. But I was not even asked to approve the script, it was simply accepted. Was this because the system knew I was an administrative user? These are the unfortunate implications of adding Script Security support to Groovy plugin. I do not think there is much we can do about this - though I agree it sucks.
Steve Cohen
added a comment - Here's another unfortunate implication: JENKINS-48522 
I'd guess the Groovy plugin should just support a non-sandbox mode for script files. Nothing to do with Script Security as well. If it gets the script approval request, it will be approved as a script