In the current state, yes. As per a conversation with Jesse Glick:
> Do not do that. Contrary to appearances, it is actually a stronger > permission than Overall/Administer. > > In order for regular users to define flows using Build Flow, the plugin > would have to be integrated with > this<https://wiki.jenkins-ci.org/display/JENKINS/Script+Security+Plugin>, > which so far it is not. Therefore as a stopgap measure it only allows > administrators to define and edit flows. > > > - Integrating it into Build Flow would probably be easy enough > (@Nicolas). The hard part is making sure the integration is usable. Users > can always request that the whole script go to a manual approval queue, > which is preferable to them having to ask you to edit the flow for them, > but you are still a bottleneck. > > So preferably they would run the script in a Groovy sandbox, which > requires no prior approval for the whole script. Making that secure > however > requires that all the individual operations in the sandbox can be safely > whitelisted, and that is tricky. Some operations, like printing a message > to the flow’s output, are no-brainers. Other operations might sound > straightforward but could be abused. The administrator can manually > whitelist operations that users actually tried, but the plugin must > provide > a reasonable default set, so that the administrator is not required to be > an expert in what is or is not safe. > > In particular, triggering builds of other jobs is problematic because > you would expect this to require the Job/Build permission (on that job), > not to be blanket whitelisted. Script Security supports whitelisting > operations which require permission checks…but does not define a mechanism > for associating an actual authentication (i.e., user) with the execution > of > the script. Jenkins core *does* define such an API, but does not > define a standard way of implementing it. The Authorize Project > plugin<https://wiki.jenkins-ci.org/display/JENKINS/Authorize+Project+plugin>provides > such an implementation (actually several), but has not yet been > reviewed by myself or Kohsuke to see if it is really secure, especially > considering corner cases such as jobs configured from REST or CLI. > > In short, this is all work that we acknowledge is needed, but have not > had the time to do yet. > > Jesse Glick > CloudBees, Inc > > On Monday, April 14, 2014 1:17:54 PM UTC-4, VFloyd wrote: > > Thanks Walter. > > So this is necessary for the "Build Flow" as well as the "Job DSL" plugin? > > > > On Monday, April 14, 2014 9:59:27 AM UTC-7, Walter Kacynski wrote: >> >> This would allow any user to run a system groovy script thru the CLI or >> Groovy Plugin. >> >> On Monday, April 14, 2014 10:17:11 AM UTC-4, VFloyd wrote: >>> >>> Morning, >>> What functionality, exactly, would I be opening up if I enable >>> "RunScripts" in our security setup? >>> >>> Thanks >>> Vanetta >>> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
