#950213 openjdk-17-jre-headless: AccessControlException in java.util.Properties when running with a security manager #950213
- Package:
- openjdk-17-jre-headless
- Source:
- openjdk-17
- Description:
- OpenJDK Java runtime, using Hotspot JIT (headless)
- Submitter:
- Brandenberger
- Date:
- 2022-10-31 17:15:04 UTC
- Severity:
- important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
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