RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions [v14]
Francisco Ferrari Bihurriet
fferrari at openjdk.org
Thu Dec 11 12:11:41 UTC 2025
On Thu, 11 Dec 2025 01:09:48 GMT, Weijun Wang <weijun at openjdk.org> wrote:
>> Hmm, I also got confused for a moment, it seems important to make a distinction between file links and directory links, and how each platform handles each of them.
>>
>> We are no longer resolving any type of link, here:
>>
>> https://github.com/openjdk/jdk/blob/c33bf62c2831acefd90ec476fcfb6d853be873ee/src/java.base/share/classes/java/security/Security.java#L250-L258
>>
>> `currentPath.resolveSibling(path)` is equivalent to `currentPath.getParent().resolve(path)` when `currentPath` has a parent.
>>
>> If `currentPath` is `/tmp/a/b/f1` and `path` is `../f2`, after line 257, path will be `/tmp/a/b/../f2`.
>>
>> In the [previous _Linux_ example](#discussion_r2607247993), `/tmp/a/b` is a **directory** symbolic link to `/tmp/x/y`, so `/tmp/a/b/../f2` still reads `/tmp/x/f2` (at the OS level) when opening the file.
>>
>> <details>
>> <summary>Extension of that <em>Linux</em> example's <code>jshell</code> snippet showing how <code>/tmp/a/b/../f2</code> can be opened</summary>
>>
>>
>> jshell -<<'EOF'
>> Path current = Path.of("/tmp/a/b/f1");
>> Path included = current.resolveSibling("../f2");
>>
>> Map<String, Path> opts = new LinkedHashMap<String, Path>();
>> opts.put("included", included);
>> opts.put("included.toRealPath()", included.toRealPath());
>> opts.put("included.toRealPath(LinkOption.NOFOLLOW_LINKS)",
>> included.toRealPath(LinkOption.NOFOLLOW_LINKS));
>> opts.put("included.normalize()", included.normalize());
>>
>> for (Map.Entry<String, Path> opt : opts.entrySet()) {
>> System.out.println();
>> System.out.println(opt.getKey() + " -> " + opt.getValue());
>> Files.newInputStream(opt.getValue());
>> System.out.println("succesfully opened");
>> }
>> EOF
>>
>>
>> Output:
>>
>>
>> included -> /tmp/a/b/../f2
>> succesfully opened
>>
>> included.toRealPath() -> /tmp/x/f2
>> succesfully opened
>>
>> included.toRealPath(LinkOption.NOFOLLOW_LINKS) -> /tmp/a/b/../f2
>> succesfully opened
>>
>> included.normalize() -> /tmp/a/f2
>> Exception java.nio.file.NoSuchFileException: /tmp/a/f2
>> at UnixException.translateToIOException (UnixException.java:92)
>> at UnixException.rethrowAsIOException (UnixException.java:106)
>> at UnixException.rethrowAsIOException (UnixException.java:111)
>> at UnixFileSystemProvider.newByteChannel (UnixFileSystemProvider.java:261)
>> at Files.newByteChannel (Files.java:380)
>> at Files.newByteChannel (Files.java:432)
>> at FileSystemProvider.newInputStream (FileSystemProvider.java:420)
>> at Files.newInp...
>
> Thanks for the detailed explanation.
>
> I like your attitude to leave the path resolution to the simplest API.
>
> For debugging output, I prefer the 3rd choice for the same reason that it's the simplest. Also, it preserves the original include form. I would assume the reader wants to see this.
Great, so I'll leave it as it currently is, and update the PR description.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24465#discussion_r2610336040
More information about the security-dev
mailing list