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

[Uwe Schindler]

Hi,

in Lucene this caused a little bit of problem in one test that used a custom policy. I fixed it:

http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/6f3f6a2d

(the relative path had to be expanded when creating the FilePermission).

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/
> -----Original Message-----
> From: Weijun Wang [mailto:weijun.wang at oracle.com]
> Sent: Friday, February 24, 2017 9:03 AM
> To: jdk9-dev at openjdk.java.net
> Cc: Uwe Schindler <uschindler at apache.org>; Rory O'Donnell
> <rory.odonnell at oracle.com>
> Subject: More change in jdk-9+158 (was: FilePermission change in jdk-9+140)
> 
> 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
> >