On Fri, 2 Jun 2023 02:01:00 GMT, Alexey Bakhtin <abakh...@openjdk.org> wrote:
>> Currently, security properties are held within the `java.security` file in >> the JDK tree for each installed JDK. The system property >> `java.security.properties` can be used to point to a file containing >> additional properties. These can be appended to the existing set or override >> all existing properties. >> >> There is currently no way to specify additional properties permanently or to >> reference multiple files. Making permanent changes to the `java.security` >> properties requires editing the `java.security` file in each JDK where the >> changes are required. >> >> This patch allows a directory tree to be specified either permanently in the >> java.security file by the `security.propertiesDir` property or on the >> command line using `java.security.propertiesDir`. Any property files found >> in this directory tree can be appended to those specified in >> `java.security`, as with the single file used by `java.security.properties`. >> >> As an example, the `security.propertiesDir` in the `java.security` file of >> each JDK can be set to a common shared directory, allowing all JDKs to share >> a common set of security properties. This eases setting up properties on >> each new JDK installation and also allows the shared properties to be >> maintained under different access permissions to those of the JDK. >> >> The command-line variant, `java.security.propertiesDir`, is intended >> primarily for testing and to disable a permanent properties directory by >> setting the value to empty. As with `java.security.properties`, the system >> property will be ignored if `security.overridePropertiesFile` in the >> `java.security` file is not set to true. >> >> A less flexible version of this patch (a permanent hardcoded single file) >> has been [used in our JDK installations since >> 2016](https://bugzilla.redhat.com/show_bug.cgi?id=1249083) to provide a >> system-wide crypto policy. Having support for this in the upstream JDK would >> allow us to remove a local patch from our builds and reduce divergence from >> upstream. > > src/java.base/share/classes/java/security/Security.java line 138: > >> 136: try { >> 137: extraPropDir = PropertyExpander.expand(extraPropDir); >> 138: stream = Files.find(Path.of(extraPropDir), >> Integer.MAX_VALUE, > > Hi @gnu-andrew , > The order of the files, returned by File::find is not defined. Different > property files can change the same security properties, and only the latest > changes will be applied. So the order of the property files is important but > seems not controlled by the propertiesDir option. That's a good point. I do recall thinking about this in the early days of considering a solution, but clearly got a bit carried away in the implementation when I realised so much of the work could be done by `Files::find`. I'm thinking we should sort the returned list of Path objects lexicographically and those that occur later in sequence then override previous ones. Any file specified by `java.security.properties` is considered as if it was the final element, overriding all others. Thus, the following files: ~~~ 01-testFile1 02-testFile2 03-testDir/extra ~~~ would result in properties in `02-testFile2` taking precedence over `01-testFile1` and those in `extra` taking precedence over those in `02-testFile2`. I'll adapt the test to check for this as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14277#discussion_r1214303435
