Control: reassign -1 openjdk-17-jre-headless
Control: retitle -1 openjdk-17-jre-headless: AccessControlException in
java.util.Properties when running with a security manager
The report is empty and I was tempted to close it as invalid. But the
underlying issue is worth considering: java.util.Properties is patched
in Debian to remove the timestamp in the header of the properties files
to make them reproducible. The timestamp is removed when the SOURCE_DATE_EPOCH
environment variable is defined.
This look trivial but this creates a subtle incompatibility compared to
the upstream JDK. Reading SOURCE_DATE_EPOCH when running with a security
manager triggers an AccessControlException unless a rule is added in the
policy file:
java.security.AccessControlException: access denied ("java.lang.RuntimePermission"
"getenv.SOURCE_DATE_EPOCH")
at
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at
java.base/java.security.AccessController.checkPermission(AccessController.java:897)
at
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
at java.base/java.lang.System.getenv(System.java:996)
at
java.base/java.util.Properties.getFormattedTimestamp(Properties.java:1587)
at java.base/java.util.Properties.store0(Properties.java:929)
at java.base/java.util.Properties.store(Properties.java:918)
So basically, any external Java application launched with the Debian JRE
and using a security manager will break when attempting to write a
properties files.
This is bad and should be reverted or done differently. We could try
adding a SOURCE_DATE_EPOCH property in jdk.internal.util.StaticProperty
since these properties are initialized before the security manager is
set. Or we could drop the patch and rely on strip-nondeterminism to
remove the timestamp.
Emmanuel Bourg
