RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions [v14]

Weijun Wang weijun at openjdk.org
Thu Dec 4 17:35:42 UTC 2025


On Thu, 4 Dec 2025 17:24:03 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 260:
>> 
>>> 258:                     // under the rationale that the person writing the
>>> 259:                     // original properties file is the one who decides
>>> 260:                     // where the relative includes should resolve.
>> 
>> The person writing the original properties file may have expected includes to resolve relative to its own location, but whoever created the symlink may have intended a different resolution path. If they wanted the original location, they could have just used the real file directly instead of introducing a symlink.
>> 
>> For a comparison, I write a tiny C program that includes another file, the included file was resolved based on the base file's named path, not its real path.
>> 
>> I know you might have a backward compatibility concern here.
>
> Hi @wangweij, indeed is a fair and interesting point of view!
> 
> I like the idea of not doing any resolution at all to get rid of the possible problems. But let me do a similar test with some other programs supporting include directives in their configuration files (such as [OpenSSL](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Other%20files%20can,ignore%20the%20include%2e), [OpenSSH](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=it%2e-,Include,inclusion%2e), [Git](https://git-scm.com/docs/git-config#_includes) and [Apache HTTP Server](https://httpd.apache.org/docs/2.4/mod/core.html#include)), to collect more real world examples (beyond C includes which you already tested).
> 
> Regarding the backward compatibility, this is not the main use case, and if we could back-port that to 25 in the future, we would get the same behavior in all the supported JDKs shipping [JDK-8319332](https://bugs.openjdk.org/browse/JDK-8319332 "Security properties files inclusion") (as 24 reached end of support).
> 
> Would you think that such a change requires a CSR? If that's the case I would support the change but in a separate enhancement, so we can get this bug fixed in 26.

Yes, it's good to see how this behaves on other programs, especially in configuration files. I know `krb5.conf` also supports it but it requires the included file having an absolute path.

> Would you think that such a change requires a CSR?

Maybe not. I see nowhere in its description in `java.security` talking about relative path resolution, so you have no specification to update.

A release note is enough, IMO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2589975871


More information about the security-dev mailing list