RFR: 8319332: Security properties files inclusion [v9]

Martin Balao mbalao at openjdk.org
Wed May 1 17:39:55 UTC 2024


On Wed, 1 May 2024 15:12:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Just one more question on the system property expansion when it's not defined. In your example:
> 
> > include ${java.home}/conf/security/profile${SecurityProfile}.security
> 
> How bad will it be if we require user to set `SecurityProfile` to `default` or an empty string if they don't need any specific profile? I'm a little concerned that user would mistype the system property name on the command line.

Requiring users to set a security property for a default configuration would turn `include` statements with a user-defined property pretty unusable in my view, even if the value were an empty string. I'd expect such user-defined property to be optional and, if not set, fall back to a secure default. With that said, this strict behavior that you are suggesting can be achieved already. Going back to the example, if profiles are defined in a way such that the file `profile_.security` does not exist but there is `profile_default.security` instead, users would be required to pass `SecurityProfile` to `default` and any mistype in the property name or value would be fatal.

With the existing `java.security.properties` property, a mistype on either the property name or value goes completely quiet. The value mistype is not ideal in my view but we don't want to introduce compatibility breaking changes there. With the proposed feature, a mistype in the property value is noticed immediately and a system administrator can optionally enforce users to always pass a correct system property name-value pair.

It is also worth noticing that users can pass `-XshowSettings:security` or `-Djava.security.debug=properties` to understand what security properties are in effect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2088819066



More information about the security-dev mailing list