-
Bug
-
Resolution: Fixed
-
Minor
-
Jenkins 2.319+, 2.303.3+
-
-
2.326
The security fixes in 2.319, LTS 2.303.3 introduced a(nother) regression:
If a SlaveToMaster(File)Callable operates on controller-local FilePath's, they are newly subject to access control.
Part of the SECURITY-2455 security fixes involved removing the per FilePath tracking of the requirement to be subject to access control, instead relying on Channel#current. That however means that all FilePath objects on the JVM executing a Callable are subject to the applicable FilePathFilter (i.e., if it's on the controller, FilePathFilter applies).
To clarify, this isn't about a MasterToSlave(File)Callable operating on a controller FilePath – those are deliberately subject to access control (and always have been). It needs code like the following to fail:
private static class LocalFileOpCallable extends SlaveToMasterCallable<String, Exception> {
@Override
public String call() throws Exception {
assertTrue(JenkinsJVM.isJenkinsJVM());
final File tempFile = Files.createTempFile("jenkins-test", null).toFile();
return new FilePath(tempFile).readToString(); // throws SecurityException
}
}
If this callable is sent from an agent to the controller for execution, it will fail with a SecurityException if agent-to-controller access control is enabled.
I do not expect any (crazy) code like this to exist, but noting just in case.
https://github.com/jenkinsci/jenkins/pull/5885 would take care of this by ripping out all FilePathFilter access control (and making FilePath methods not work in agent-to-controller direction).