Integrated: 8352728: InternalError loading java.security due to Windows parent folder permissions

[Francisco Ferrari Bihurriet]

On Sat, 5 Apr 2025 02:36:43 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

> Hi, this is a proposal to fix [JDK-8352728](https://bugs.openjdk.org/browse/JDK-8352728 "InternalError loading java.security due to Windows parent folder permissions").
> 
> Path resolution with `Path::toRealPath` fails under the following conditions:
> 
> * When there is a restricted [_ACL_](https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) in a parent directory (_Windows_)
> * When dealing with an anonymous file only accesible through the _procfs_, such as `/proc/<pid>/fd/<fd>` (_Linux_)
>     * Such a file can be created by a pipe, deleting an opened file, or with the [`memfd_create` _Linux_ API](https://man7.org/linux/man-pages/man2/memfd_create.2.html)
> 
> Original code from [JDK-8319332: Security properties files inclusion](https://bugs.openjdk.org/browse/JDK-8319332) unconditionally resolves with `Path::toRealPath` all the processed properties files. This PR avoids resolving any paths. Cyclic includes detection is now performed with the unresolved paths and `Files::isSameFile`, so `activePaths` no longer needs to be a `Set`.
> 
> <details>
> <summary>Previous approach and rationale for resolving <strong>file</strong> symlinks (kept here for historical reasons).</summary><br>
> 
> In _Linux_, a relative `include` from an anonymous file referenced as `/proc/<pid>/fd/<fd>` makes little sense.
> 
> However, in _Windows_, a relative `include` from a file where any of the parent directories has a restricted _ACL_ will be expected to work. It's important to note that such a restricted directory permissions scenario occurs to every [_UWP_](https://learn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) app (see [JDK-8369741](https://bugs.openjdk.org/browse/JDK-8369741 "cannot use java.security inside of UWP apps")).
> 
> When computing a relative `include`, we were performing symlinks resolution of the parent file under the rationale that the person writing the original properties file is the one who decides where the relative includes should resolve. This reasoning has been nuanced and re-evaluated in a [subsequent discussion](#discussion_r2585623241).
> 
> The original idea was to replace [`java.nio.file.Path::toRealPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toRealPath(java.nio.file.LinkOption...)) by [`java.io.File::getCanonicalPath`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#getCanonicalPath()) for path canonicalization purposes. The decision wa...

This pull request has now been integrated.

Changeset: 7e1051bf
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e1051bfcc01aad538376c86354e16e25d2eaf7a
Stats:     2106 lines in 7 files changed: 1123 ins; 978 del; 5 mod

8352728: InternalError loading java.security due to Windows parent folder permissions

Reviewed-by: weijun, mullan

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

PR: https://git.openjdk.org/jdk/pull/24465