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

[Francisco Ferrari Bihurriet]

On Wed, 3 Dec 2025 15:41:21 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Francisco Ferrari Bihurriet has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Convert ConfigFileTestAnonymousPipes to Java
>>  - Review suggestion: go back tolerating IOException
>>    
>>    We agreed an IOException in this case is recoverable, and decided to
>>    tolerate it, while adding a debug log message with the exception.
>>  - Review suggestion: improve comment clarity
>
> 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.

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

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