More change in jdk-9+158 (was: FilePermission change in jdk-9+140)

[Weijun Wang]

Hi Again

The following changeset is included in jdk-9+158:

    http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8b0d55e02f54

As said in the parent mail below:

 >> 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).

In fact, we did try to cover 3rd-party Policy implementations last time, 
but it turns out not working perfectly, and we've disabled it in 
JDK-8168410.

If you have a user-defined Policy implementation that grants 
FilePermission on ${user.dir}/-, reading a file in the current directory 
using its base name will fail.

Still the same solution: Ensure that the path used in permission 
granting has the same style as the one how you access the file.

Setting -Djdk.security.filePermCompat=true will take you back to the 
jdk-9+140 behavior. Setting -Djdk.io.permissionsUseCanonicalPath=true 
will take you back to the jdk8 behavior.

Any feedback is welcome.

Thanks
Max

On 10/14/2016 10:03 PM, Wang Weijun wrote:
> Hi All
>
> 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
>   http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4251b451be17
>
> 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
>
>   http://download.java.net/java/jdk9/docs/api/java/io/FilePermission.html
>
> 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.
>
> Thanks
> Max
>