The implication of the JDK-8194154 fix in jdk8u342.

[hedongbo]

Hi,
 
After in-depth communication with customers, we found that when customers upgraded JDK to 8u232,
`java.lang.RuntimeException: default directory must be absolute` exception was thrown, which causes the product to fail to
start(introduced by JDK-8213429[1], CVE-2019-2933). The following is a simple case:

$ cat Foo.java
public class Foo {
    public static void main(String[] args) {
        System.out.println("foo");
    }
}
$ openjdk-8u222-b10/bin/java -Duser.dir=. Foo foo $ openjdk-8u232-b09/bin/java -Duser.dir=. Foo
Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.ExceptionInInitializerError
            at sun.net.www.protocol.file.FileURLConnection.getPermission(FileURLConnection.java:225)
            at java.net.URLClassLoader.getPermissions(URLClassLoader.java:666)
            at sun.misc.Launcher$AppClassLoader.getPermissions(Launcher.java:360)
            at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
            at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
            at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
            at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
            at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
            at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
            at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
            at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
Caused by: java.lang.RuntimeException: default directory must be absolute
            at sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:54)
            at sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
            at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46)
            at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39)
            at sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.java:56)
            at sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvider.java:41)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
            at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
            at java.lang.Class.newInstance(Class.java:442)
            at sun.nio.fs.DefaultFileSystemProvider.createProvider(DefaultFileSystemProvider.java:48)
            at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:63)
            at java.io.FilePermission.<clinit>(FilePermission.java:187)
            ... 15 more
$ openjdk-8u232-b09/bin/java -Duser.dir=$PWD Foo
foo

Our customer changed to use absolute path in -Duser.dir as a workaround, so in fact this patch doesn't help the customer's problem.

But we found that customers should not change the value of user.dir, believing that JDK-8194154 is a JDK bug and should be backported to jdk8u.
Unfortunately, we didn't realize that this would bring us compatibility issues. I apologize for this.
 
I agree to revert this patch in JDK8 to maintain backward compatibility, apologize again.

[1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b148d99d5cc3
 
Thanks,
hedongbo

-----Original Message-----
From: Langer, Christoph <christoph.langer at sap.com> 
Sent: Saturday, July 23, 2022 5:33 AM
To: hedongbo <hedongbo at huawei.com>; Sergey Bylokhov <bylokhov at amazon.com>; jdk8u-dev at openjdk.org; Andrew Hughes <gnu.andrew at redhat.com>
Cc: Chenshanyao <chenshanyao at huawei.com>
Subject: RE: The implication of the JDK-8194154 fix in jdk8u342.

Hi,

out of interest, I was playing a bit with JDK-8194154 and I agree that it should not have been backported to 8u in first place and should definitely be reverted. The effect of the fix is simply to not honor a change of System property "user.dir" within Java code any longer in nio Path handling. This is a change in behavior which should be avoided in update releases.

The patch in itself is questionable since the potential crash that should be addressed by the fix is still lurking and can be reproduced by starting the VM with a -D option, e.g. -Duser.dir="/home/a/b/c/". That is still possible with current JDK11, by the way. It must have been fixed somehow in between 11 and 17.

And furthermore, I also doubt that the problem that the backporters of this patch wanted to address, e.g. to avoid issues starting the VM when a relative path is set via -Duser.dir, would be fixed. This can still be reproduced with JDK-8194154 applied. It must have been fixed with another change between 8 and 11.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of hedongbo
> Sent: Donnerstag, 21. Juli 2022 04:01
> To: Sergey Bylokhov <bylokhov at amazon.com>; jdk8u-dev at openjdk.org; 
> Andrew Hughes <gnu.andrew at redhat.com>
> Cc: Chenshanyao <chenshanyao at huawei.com>
> Subject: RE: The implication of the JDK-8194154 fix in jdk8u342.
> 
> The initial reason is that the customer set -Duser dir=./xxx relative 
> path, resulting in an error: Error: Could not find or load main class xxx.
> Unfortunately, we can't get the customer's code, so PR uses the tes 
> case that comes with the original fix to illustrate this problem.
> 
> Thanks,
> hedongbo
> 
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of Sergey 
> Bylokhov
> Sent: Thursday, July 21, 2022 4:28 AM
> To: jdk8u-dev at openjdk.org; Andrew Hughes <gnu.andrew at redhat.com>
> Subject: The implication of the JDK-8194154 fix in jdk8u342.
> 
> Hello, the last release of jdk8u includes the fix for JDK-8194154[1] 
> which disabled the possibility to change the "user.dir" property.
> 
> Changing the "user.dir" was not recommended from the beginning but it 
> was not forbidden, so there are some old applications that rely on the old behavior.
> One of the app which sets the "user.dir" is Gradle. The Gradle has a 
> notice in the documentation for the user:
> "Never use new File(relative path) because this creates a path 
> relative to the current working directory (CWD). Gradle can make no 
> guarantees about the location of the CWD, which means builds that rely 
> on it may break at any time".
> 
> But for compatibility reasons they still set the "user.dir" property, 
> so the old plugins will work.
> Now that compatibility is broken due to the fix I mention. We found 
> such apps immediately after the release.
> 
> I would like to ask what was the reason for the backport, is it 
> critical enough to change a behavior? I did not find any broad 
> discussion about that backport nor the reason why it was pushed but I 
> would like to bring a compatibility concerns about that change. I think we should roll it back as soon as possible.
> 
> Please share your opinions?
> 
> [1] https://bugs.openjdk.org/browse/JDK-8194154
> 
> --
> Best regards, Sergey.