(Created a public ticket after a vulnerability was reported as SECURITY-2149 but considered by the maintainers as a feature)

The plugin checks for `containerId.isPresent()`, then tries to mount all volumes mounted on the Jenkins container on the new Job container.

This is exactly what I want to prevent since it poses a huge attack surface for untrusted code.

https://github.com/jenkinsci/docker-workflow-plugin/blob/1089131014350e11adfa364d34e7717954350261/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L168

Suggestion: make this behaviour configurable.

Some comments from the ticket:

On the Jenkins agent container. Which should be considered untrusted, and running in an isolated daemon for example in an agent VM. (If you run builds on the controller, or share a daemon between controller and agents, you might as well just disable security.)

I agree that the behavior should be made configurable, and that it should be disabled by default for the Jenkins controller.

There are use-cases when it potentially makes sense to allow controller volume mapping, e.g. in Jenkinsfile Runner executions which cannot be considered "trusted" due to their architecture (same as agent).