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] 
> <javascript:>>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] <javascript:>.
>> 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].
For more options, visit https://groups.google.com/d/optout.

Reply via email to