Execution with SecurityManager fails with 3.2.0-RC1

[sdusart]

Our application is composed by several executable jars produced by the spring-boot-maven-plugin.
We use the 21.0.1-zulu JVM with the security manager activated as we need to run user-defined scripts.

With springboot 3.2.0-M3 everything still works as expected; with 3.2.0-RC1 (after the reimplementation of the Nested Jar Support) the application fails to start.

Our policy file is :

// The application code gets all permissions (${app.dir} is the directory where the executable jars are)
grant codeBase "file:${app.dir}/*" {
  permission java.security.AllPermission;
};

// grants for specific codebase

// permissions given by default
grant {
  permission java.util.PropertyPermission "*", "read";
  permission java.lang.RuntimePermission "accessClassInPackage.sun.util.calendar";
};

With 3.2.0-RC1, the error is :

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:91)
	at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:53)
	at org.springframework.boot.loader.launch.JarLauncher.main(JarLauncher.java:54)
Caused by: java.lang.IllegalArgumentException: Unable to instantiate factory class [org.springframework.boot.autoconfigure.SharedMetadataReaderFactoryContextInitializer] for factory type [org.springframework.context.ApplicationContextInitializer]
	at org.springframework.core.io.support.SpringFactoriesLoader$FailureHandler.lambda$throwing$0(SpringFactoriesLoader.java:651)
	at org.springframework.core.io.support.SpringFactoriesLoader$FailureHandler.lambda$handleMessage$3(SpringFactoriesLoader.java:675)
	at org.springframework.core.io.support.SpringFactoriesLoader.instantiateFactory(SpringFactoriesLoader.java:231)
	at org.springframework.core.io.support.SpringFactoriesLoader.load(SpringFactoriesLoader.java:206)
	at org.springframework.core.io.support.SpringFactoriesLoader.load(SpringFactoriesLoader.java:160)
	at org.springframework.boot.SpringApplication.getSpringFactoriesInstances(SpringApplication.java:477)
	at org.springframework.boot.SpringApplication.getSpringFactoriesInstances(SpringApplication.java:473)
	at org.springframework.boot.SpringApplication.<init>(SpringApplication.java:282)
	at org.springframework.boot.builder.SpringApplicationBuilder.createSpringApplication(SpringApplicationBuilder.java:115)
	at org.springframework.boot.builder.SpringApplicationBuilder.<init>(SpringApplicationBuilder.java:102)
	at org.springframework.boot.builder.SpringApplicationBuilder.<init>(SpringApplicationBuilder.java:98)
	at com.alsyontech.thetys.ingestion.Ingestion.main(Ingestion.java:16)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	... 4 more
Caused by: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
	at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
	at java.base/java.security.AccessController.checkPermission(AccessController.java:1071)
	at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
	at java.base/java.lang.reflect.AccessibleObject.checkPermission(AccessibleObject.java:92)
	at java.base/java.lang.reflect.Constructor.setAccessible(Constructor.java:185)
	at org.springframework.util.ReflectionUtils.makeAccessible(ReflectionUtils.java:201)
	at org.springframework.core.io.support.SpringFactoriesLoader$FactoryInstantiator.<init>(SpringFactoriesLoader.java:373)
	at org.springframework.core.io.support.SpringFactoriesLoader$FactoryInstantiator.forClass(SpringFactoriesLoader.java:397)
	at org.springframework.core.io.support.SpringFactoriesLoader.instantiateFactory(SpringFactoriesLoader.java:227)
	... 14 more

With -Djava.security.debug=access,failure, I can see several denied accesses (see failure.log).

As indicated in https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.2.0-RC1-Release-Notes , when I add <loaderImplementation>CLASSIC</loaderImplementation> to the spring-boot-maven-plugin configuration, everything works fine.

[wilkinsona]

Thanks for trying the release candidate. I can't explain why the loader implementation makes a difference here, but we haven't supported using the SecurityManager since Spring Boot 3.0. This change was motivated by its deprecation in the JDK and followed Spring Framework's lead.

You could continue with the classic loader implementation for now but you should move away from relying on the security manager as it isn't supported by Spring Boot or Spring Framework.

I'll leave this issue open for now as we should investigate to figure out why the behavior has changed. It may be that the security manager not working is a symptom of a broader problem and something that we do support is also affected.

[wilkinsona]

I can't explain why the loader implementation makes a difference here

I think I can explain this now. When using the new loader implementation, the code source URLs change to jar:nested: URLs and they do not match the grants in the security.policy file. It may be possible to get this to work by changing the policy but, given that the security manager isn't support, I wouldn't recommend spending time doing so.

I don't think this change in behaviour is a symptom of a broader problem so I don't think there's any action for us to take here.