RFR: 8352728: InternalError loading java.security due to Windows parent folder permissions [v13]
Francisco Ferrari Bihurriet
fferrari at openjdk.org
Tue Dec 2 19:48:24 UTC 2025
On Tue, 2 Dec 2025 17:02:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Address review comments
>> - Slightly improve ConfigFileTestDirPermissions
>>
>> Extract restrictedAcl() AutoCloseable and also use AutoCloseable for the
>> temporary directory cleanup.
>
> Please confirm if I understand correctly. So the current fix covers both this bug and the Windows UWP regression. However, if relative include is used in Windows UWP, it is still a problem. Is this right?
>
> If so, if one day someone brings up the relative include problem in Windows UWP, do you expect a different fix that will overwrite this one? Or is it the Windows admin's duty to add more permissions?
Hi @wangweij,
> Please confirm if I understand correctly. So the current fix covers both this bug and the Windows UWP regression. However, if relative include is used in Windows UWP, it is still a problem. Is this right?
Yes.
> If so, if one day someone brings up the relative include problem in Windows UWP, do you expect a different fix that will overwrite this one? Or is it the Windows admin's duty to add more permissions?
I'm not an UWP expert by any means, but I think that changing permissions would be, at the very least, a bad practice (because it would weaken the isolation of the apps).
If the problem is brought up in the future, I would start a discussion with the core-libs team to see what are our alternatives. Between JDK 24 and #27324 (e.g. current JDK 25), `File::getCanonicalFile` was behaving in a way that worked well for this use case, but that was probably a non-guaranteed behavior by the API.
The exchange with the core-libs team should try to go in the direction of answering when a filesystem link/junction should be considered resolvable, under the lack of parent permissions, on each platform. If the answer is "never", is there an API (or should we introduce one?) that can tell us whether a filesystem link/junction exists? (in cases where we are sure there isn't a link/junction, we can use `Path::toAbsolutePath` as a fallback). What do other runtimes do? Does exist a known OS-level API capable of giving a valid resolution for the path under this permissions scenario? If it does, is "never" still a valid answer to the first question?
In parallel, on the security-libs side, we could try fo find any best-effort worth exploring. For example, do we want to unconditionally use `Path::toAbsolutePath` as a fallback, and document something in line with "in the absence of parent directory permissions, all the relative includes will be computed using the unresolved path as the base"?
#### Workaround
In the meantime, we could recommend trying to find a system property that allows the _Windows UWP_ app to calculate the path as an absolute one.
For example, if the file is in the same directory as `java.security`, instead of:
include other.properties
Use:
include ${java.home}\\conf\\security\\other.properties
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24465#issuecomment-3603693159
More information about the security-dev
mailing list