On Tue, 2 Dec 2025 17:02:45 GMT, Weijun Wang <[email protected]> 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

Reply via email to