I'll just disable that execution and your enforcer is defanged ! On Monday, 10 March 2014, Christian Willman <[email protected]> wrote:
> Stephen, > > No biggie for us. We use the Maven enforcer plugin to ban antrun and exec. > :-) > > Cheers, > Christian > > On Monday, March 10, 2014 7:56:49 AM UTC-4, Stephen Connolly wrote: >> >> Like that's going to stop them... >> >> <plugin> >> <groupId>org.codehaus.mojo</groupId> >> <artifactId>exec-maven-plugin</artifactId> >> <version>1.2.1</version> >> <executions> >> <execution> >> <goals> >> <goal>exec</goal> >> </goals> >> <configuration> >> <executable>/bin/rm</executable> >> <workingDirectory>/</workingDirectory> >> <arguments> >> <argument>-rf</argument> >> <argument>/</argument> >> </arguments> >> </configuration> >> </execution> >> </executions> >> </plugin> >> >> >> >> On 10 March 2014 00:39, Christian Willman <[email protected]> wrote: >> >>> Unfortunately it is not possible. A common suggestion is to template out >>> your specific job type, but even then, there is no authorization strategy >>> to prevent users from simply creating a new FreestyleBuild with a console >>> build step. >>> >>> Our organization has the same requirements -- we cannot allow untrusted >>> developers to run arbitrary shell commands. We've solved this by switching >>> to an external templating system (which I wrote in-house). Now developers >>> cannot create or modify *any* jobs directly through the Jenkins UI. >>> This works for us because 99% of our Java projects can be built with a >>> simple "mvn clean deploy". The oddball jobs are isolated to a >>> heavily-audited Jenkins instance. >>> >>> Another potential solution is to implement your own job types and then >>> write a custom authorization strategy which revokes access to the built-in >>> job types. But this is not maintainable and will probably require a >>> dedicated admin to babysit the implementation for the foreseeable future. >>> >>> I've searched through the source and couldn't figure out any other >>> implementations which don't require modifications to the Jenkins core. >>> Unfortunately nobody (including Cloudbees) seems interested in this use >>> case right now. >>> >>> Cheers, >>> Christian >>> >>> -- >>> 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. >>> >> >> -- > 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]<javascript:_e(%7B%7D,'cvml','jenkinsci-users%[email protected]');> > . > For more options, visit https://groups.google.com/d/optout. > -- Sent from my phone -- 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.
