Imagine a default Jenkins setup consisting of a single master instance ... a test running on master instance writing to a disk file could potentially ruin the master installation overwriting or deleting the Jenkins configuration files.
This does not feel right, considering this scenario an emphasis could be put on a better security setup consisting of a
- robust backend with REST APIs
- jailed workers (chroot, docker container, etc.)
- secured messaging backbone for communication between the core and the workers
IMHO and TBD
I did not find a lot of evidence of this topic so far, it might be quite off track of the current jenkins philosophy compromising a bit of security for usability purposes. However security issues are subject to be discussed in enterprise environments and targeting those might be a viable direction.