On Wed, 3 Dec 2025 01:48:00 GMT, Francisco Ferrari Bihurriet <[email protected]> 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 the paths unless strictly necessary: when determining the >> base path to compute a relative `include` directive. Cyclic includes >> detection is now performed with the unresolved paths and >> `Files::isSameFile`, so `activePaths` no longer needs to be a `Set`. >> >> #### Still unsupported use-case >> >> 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 perform 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. In the absence of a recommended way or API to deal with resolution >> under this restricted directory permissions scenario, this use-case is left >> unsupported. This compromise-solution is better than the current status of >> _UWP_ apps, where simply loading the `java.security.Security` class breaks >> the JVM initialization by a failed attempt to resolve the `java.security` >> path (not from an `include` statement, nor a relative path). >> >> <details> >> <summary>Previous approach and... > > 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 tried `jextract` on a C header that includes another header, the included file was resolved based on the header’s named path, not its real path. I know you might have a backward compatibility concern here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2585623241
