FilePermission change in jdk-9+140
weijun.wang at oracle.com
Fri Oct 14 14:03:11 UTC 2016
If you use a security manager and file permissions then read on.
The following changeset is included in jdk-9+140:
8164705: Remove pathname canonicalization from FilePermission
This code change removes pathname canonicalization from FilePermission creation, thus calculations of the equals() and implies() methods will be based on the raw path string one provides in "new FilePermission(path, action)".
The new behavior is described as @implNote at various places in
We do this mainly for performance enhancement so that there is no need to consult the file system every time a FilePermisson is created.
This means FilePermissions on the following pathnames will be unrelated:
1. On "./file" and "/path/to/current/directory/file".
2. On symlink and its target.
3. On "C:\Program Files" and "C:\PROGRA~1" on Windows.
and any other name change that a canonicalization can make.
Please note that the new FilePermission implementation is based on NIO Path, and Path happens to understand case-sensitiveness and various other things, so there is no need to worry about "C:\PATH" and "c:\path" on Windows or abundant ./down/.. on all platforms.
That said, this changeset also adds a compatibility layer at the permission check level to translate between an absolute pathname and a relative one. So, even if FilePermission on a relative path does not imply one on an absolute path pointing to the same file, when you grant a permission in a relative pathname, you are still allowed to read the file with an absolute pathname.
This compatibility layer covers these cases:
1. When a permission is granted in a policy file.
2. When a permission is automatically granted because it's on a path where the class files are stored.
3. When a permission is requested in a doPrivileged-with-permissions call
We do hope that whenever you want to access a file, the permission you granted in a policy would be better to match the pathname you use to access the file. For example, if you plan to call 'new FileInputStream("/home/me/x")', please also grant FilePermission on "/home/me/x" instead of just "x".
Please note the compatibility layer does NOT cover:
1. A user-defined security manager or policy implementation, because we cannot control it. (Not always, but you need to test).
2. The translation between a symlink and its target, because it needs to read the file system.
3. The translation between a Windows long file name and its DOS-8.3 shorted name, because it needs to read the file system.
Also, "/-" does not imply "./file" even if it's a Unix. Please use "<<ALL FILES>>" instead.
Finally, if you cannot live with this new behavior and like the pre-jdk9 style, you can always set the system property jdk.io.permissionsUseCanonicalPath back to true.
More information about the jdk9-dev