RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException

[Erik Gahlin]

On Mon, 18 Oct 2021 07:05:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> > Why do you get a SecurityException?
> > This doesn't happen with "JFR.start filename=...." and is ignoring the path (and logging) really the correct way to handle it?
> 
> We can see this error when SecurityManager is enabled (e.g. TestStreamingRemote.java). `Options::setDumpPath` calls both `File::canWrite` and `Path::toRealPath`, then they requires `("java.io.FilePermission" "." "write")` - `SecurityManager::checkWrite` performs correctly. In case of `filename` of JFR.start does not seem to check with same way.
> 

I looked at this more. 

The reason you get a SecurityException is because setDumpPath is set during initialization with DEFAULT_DUMP_PATH. when the JVM and Options class are initialized. It's not related to "JFR.configure dumppath=..."

This means this will always happen when a security manager is in use and JFR is initialized. I don't think what you have is a proper solution. As I understand it, the reason you need to resolve the path in Java is because you can't just use the text (in user.home) as is (it will not work with native). Correct?

I'm not sure we should use user.home at all. Shouldn't the default path be where the JVM process started? 

A more appropriate solution seems to be to get the path using SecuritySupport, either using an existing method or one you add as part of this fix. This will however slow down startup. 

Perhaps an even better solution is to let "null" be the process starting directory and let native handle it? No need to resolve it in Java during startup. Remove DEFAULT_USER_HOME in the SecuritySupport class. One problem with this approach is that Options.getDumpPath() needs to be updated to return the process start directory when it is null. This can perhaps be done using a call to native, or using SecuritySupport, so we don't get a SecurityException. This will only happen when jfr=debug is  set, or somebody calls "JFR.configure". If you choose this approach, make sure it works in those scenarios. In general, always run tests in open/test/jdk/jdk/jfr before integrating a JFR fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5984