RFR: 8309330: Allow java.security to be extended via a properties directory

[Andrew John Hughes]

On Fri, 2 Jun 2023 02:01:00 GMT, Alexey Bakhtin <abakhtin at 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