RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions
Alan Bateman
alanb at openjdk.org
Fri Oct 17 10:10:36 UTC 2025
On Thu, 1 May 2025 10:35:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>>> File::getCanonicalPath seems to take the best-effort approach (both in Linux and Windows), whereas Path::toRealPath is stricter.
>>
>> Path::toRealPath is doing the right thing, and consistent with realpath(2). The issue with File::getCanonicalXXX is that it is specified to return a canonical file even if it doesn't exist, so this is why you see a lot more code to compute a result.
>>
>> Maybe the recursive include check them maybe it should use the file key instead.
>
>> @AlanBateman are you ok with letting the original [c6f1d5f](https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab) reviewers know of this fix and take a look? Or do you think further discussion is needed somewhere else?
>
> Have you had time to try using the file key to detect the recursive include case?
> Hi @AlanBateman, I'm resuming the work on this one.
>
> > Have you had time to try using the file key to detect the recursive include case?
>
> By "file key", do you mean `Files.readAttributes(Path.of("..."), BasicFileAttributes.class).fileKey()`? This works on _Linux_ but returns `null` on _Windows_.
Can you try Files.isSameFile? It will use the file key on all platforms. If the file located by the included path, and the previous files encountered, are accessible then it can be loadFromPath..
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3414764843
More information about the security-dev
mailing list