JDK-8352728 : InternalError loading java.security due to Windows parent folder permissions
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 24,25,26
  • Priority: P3
  • Status: In Progress
  • Resolution: Unresolved
  • OS: windows
  • CPU: x86_64
  • Submitted: 2025-03-24
  • Updated: 2025-12-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26Unresolved
Related Reports
Causes :  
Duplicate :  
Description
If jdk-24 on Windows x64 is installed within a sub-folder of a parent for which your "users" does not have access, then when java.security is accessed a java.lang.InternalError is generated.

Re-create:
1. Create a Windows file system setup with the following security:
- c:\parent_folder : No user permissions
-     c:\parent_folder\jdk\jdk-24 : JDK HOME folder, with user permissions
2. Run a testcase that causes c:\parent_folder\jdk\jdk-24\conf\security\java.security to be loaded, eg:
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;


public class md5test {
    public static void main(String[] args) {
        String message = "Text";
        try {
            MessageDigest md = MessageDigest.getInstance("SHA-256");
            md.update(message.getBytes());
            byte[] digest = md.digest();
            System.out.println("Message: " + message);
            System.out.println("SHA-256 Hash: " + bytesToHex(digest));
        } catch (NoSuchAlgorithmException e) {
            System.err.println("Error: SHA-256 algorithm not available.");
            e.printStackTrace();
        }
    }

    private static String bytesToHex(byte[] bytes) {
        StringBuilder sb = new StringBuilder();
        for (byte b : bytes) {
            sb.append(String.format("%02x", b));
        }
        return sb.toString();
    }
}

Run testcase, fails as follows:
Exception in thread "main" java.lang.InternalError: Error loading java.security file
        at java.base/java.security.Security$SecPropLoader.loadMaster(Security.java:142)
        at java.base/java.security.Security$SecPropLoader.loadAll(Security.java:120)
        at java.base/java.security.Security.initialize(Security.java:326)
        at java.base/java.security.Security.<clinit>(Security.java:315)
        at java.base/sun.security.jca.ProviderList.<init>(ProviderList.java:170)
        at java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:89)
        at java.base/sun.security.jca.Providers.<clinit>(Providers.java:55)
        at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:144)
        at java.base/java.security.MessageDigest.getInstance(MessageDigest.java:185)
        at md5test.main(md5test.java:10)
Caused by: java.nio.file.AccessDeniedException: C:\parent_folder\jdk\jdk-24\conf\security\java.security
        at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:96)
        at java.base/sun.nio.fs.WindowsLinkSupport.getRealPath(WindowsLinkSupport.java:280)
        at java.base/sun.nio.fs.WindowsPath.toRealPath(WindowsPath.java:907)
        at java.base/sun.nio.fs.WindowsPath.toRealPath(WindowsPath.java:42)
        at java.base/java.security.Security$SecPropLoader.loadFromPath(Security.java:269)
        at java.base/java.security.Security$SecPropLoader.loadMaster(Security.java:139)
        ... 9 more

Comments
[~mullan]: ok, the PR is awaiting for reviews of all the analyses and the alternatives (https://github.com/openjdk/jdk/pull/24465#issuecomment-3114241142). I didn't ask [~weijun] a review (original JDK-8319332 reviewer) because I first wanted to reach an agreement with [~alanb].
16-10-2025

Raising to P3 given that there has been another bug filed on this: https://bugs.openjdk.org/browse/JDK-8369741
16-10-2025

Summary of my findings and posture ============================ We perform symlinks resolution of each security properties file path under the rationale that the original file writer is the one who decided where the relative includes should resolve. While canonicalization could be delayed until a relative include is found, its current location offers a shortcut for cycle detection and preciser debugging output when -Djava.security.debug=properties is employed. We prefer java.io.File::getCanonicalFile over java.nio.file.Path::toRealPath because the former is more fault-tolerant, since the canonical form of a pathname is specified to exist even for nonexistent/inaccessible files. In Windows, File::getCanonicalFile handles restricted permissions in parent directories where Path::toRealPath fails with AccessDeniedException. For a full dig on this behavioral difference, please refer to the pull request body: https://github.com/openjdk/jdk/pull/24465#issue-2973770332 In Linux, File::getCanonicalFile handles anonymous pipes (such as /dev/stdin when it comes from a pipe) where Path::toRealPath fails with NoSuchFileException. For a full dig on this behavioral difference, please refer to the following pull request comment: https://github.com/openjdk/jdk/pull/24465#issuecomment-2803609222
15-04-2025

This will require discussion on nio-dev, and also some understanding from security-dev as to why toRealPath is used here.
10-04-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24465 Date: 2025-04-05 02:36:43 +0000
10-04-2025

Or possibly introduced by https://bugs.openjdk.org/browse/JDK-8344397 I think given it's a valid Permission setup for a Windows user, ie. using a JDK within a sub-folder of a parent PATH to which they don't have full access, it sounds like a bug to me.
27-03-2025

Re-assigning to [~fferrari] for further evaluation.
27-03-2025

[~aleonard] This is a simple file permissions issue introduced in jdk-24 by JDK-8319332. It doesn't look like a valid bug to me.
26-03-2025

Note this passes on jdk-23.0.2+7, so is a regression.
24-03-2025