JDK-8278894 : access denied with windows-special files, like like "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}"
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 11,17,18,19
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_10
  • CPU: generic
  • Submitted: 2021-12-15
  • Updated: 2022-02-09
  • Resolved: 2022-02-07
Related Reports
Duplicate :  
JDK-8193563 - FileSystemView::getFiles throws SecurityException which is not mentioned in its specification.
Description
ADDITIONAL SYSTEM INFORMATION :
Microsoft Windows [Version 10.0.19042.985]

openjdk version "11.0.11" 2021-04-20 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.11+9-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.11+9-LTS, mixed mode)

working as expected with:

java version "1.8.0_171"
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)



A DESCRIPTION OF THE PROBLEM :
We need to run an application with SecurityManager enabled.
Now we run into problems with JFileChooser - for example clicking on computer-icon.
The security-policy, which worked (long) before, does not so anymore.

I could reduce the problem to test with SecurityManager.checkRead(String) - see sourcecode.

Digging deeper it looks like these special Windows-filenames (like "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}") were jus ignored before, but produce now errors.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
run the test code

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
no exception
ACTUAL -
access denied exception

---------- BEGIN SOURCE ----------
SecMan.policy:

grant {

  /* --- Computer-Symbol links --- */
  permission java.io.FilePermission "ShellFolder: 0x11", "read";
  permission java.io.FilePermission "ShellFolder: 0x11${/}-", "read";
  /* --- Netzwerk-Symbol links --- */
  permission java.io.FilePermission "ShellFolder: 0x12", "read";
  permission java.io.FilePermission "ShellFolder: 0x12${/}-", "read";
  /* --- Computer dropdown --- */
  permission java.io.FilePermission "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}", "read";
  permission java.io.FilePermission "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}${/}-", "read";
  /* --- Netzwerk dropdown --- */
  permission java.io.FilePermission "::{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}", "read";
  permission java.io.FilePermission "::{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}${/}-", "read";
  /* --- Bibliotheken dropdown --- */
  permission java.io.FilePermission "::{031E4825-7B94-4DC3-B131-E946B44C8DD5}", "read";
  permission java.io.FilePermission "::{031E4825-7B94-4DC3-B131-E946B44C8DD5}${/}-", "read";

  /* permission java.io.FilePermission "<<ALL FILES>>", "read"; */
};

SecMan.java:

public class SecMan {
  public static void main(final String[] args) {
    System.setProperty("java.security.policy", "SecMan.policy");
    final String wfn = "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}";
    System.out.printf("%s -> %s%n", wfn, new File(wfn).getPath());
    new SecurityManager().checkRead(wfn);
  }
}


---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
none - except not enabling security

FREQUENCY : always
Comments
We discussed on this issue and given that the SecurityManager is deprecated for removal and the FilePermission behavior is written into the spec, we hesitate to make any code change and plan to close this bug as Will-Not-Fix. There is a workaround that one can create their own SecurityManager like below. Just add any shell folder name or pattern they want to bypass. public static class MySM extends SecurityManager { @Override public void checkRead(String file) { if (file.equals("ShellFolder: 0x11") || ...) return; super.checkRead(file); } }
09-02-2022
I think the first line of the attached policy file has a problem. Please remove the 'codeBase "file:/"' string. Then on JDK 8u you can see two icons on the left column of the dialog box. On JDK 9 and higher, they do not show up.
19-01-2022
The observations with new test code on Windows 10: javac --add-exports=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED SecMan.java java --add-exports=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED -Djava.security.manager -Djava.security.policy==C:\Users\TONGWAN\Documents\JI-9072184\src\SecMan.policy SecMan JDK 8: Failed, AccessControlException thrown. JDK 11: Failed. JDK 17: Failed. JDK 18ea+29: Failed. JDK 19ea+3: Failed.
19-01-2022
Further information from the submitter: 1) You need to specify the security on commandline. -Djava.security.manager -Djava.security.policy==SecMan.policy 2) Looks like, it is WindowsLookAndFeel-dependent. Here another testcase: import java.awt.EventQueue; import java.io.File; import javax.swing.JFileChooser; import javax.swing.UIManager; import javax.swing.UnsupportedLookAndFeelException; import com.sun.java.swing.plaf.windows.WindowsLookAndFeel; public class SecMan { static void checkRead() { final String wfn = "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}"; System.out.printf("%s -> %s%n", wfn, new File(wfn).getPath()); try { System.getSecurityManager().checkRead(wfn); } catch (final Exception e) { e.printStackTrace(); } } static void withJFC() throws ClassNotFoundException, InstantiationException, IllegalAccessException, UnsupportedLookAndFeelException { UIManager.setLookAndFeel(WindowsLookAndFeel.class.getName()); EventQueue.invokeLater(() -> { final int res = new JFileChooser().showOpenDialog(null); System.out.println(res); System.exit(res); }); } public static void main(final String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException, UnsupportedLookAndFeelException { // checkRead(); withJFC(); } }
23-12-2021
The issue looks like a duplicate of JDK-8193563. The observations on Windows 10: JDK 8: Failed, AccessControlException thrown. JDK 11: Failed. JDK 17: The SecurityManager is deprecated.
16-12-2021