RFR: 8275375: jfr/api/consumer/security/TestStreamingRemote.java fails with AccessControlException
Yasumasa Suenaga
ysuenaga at openjdk.java.net
Mon Oct 18 11:27:53 UTC 2021
On Mon, 18 Oct 2021 07:57:15 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:
> 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=..."
I concern SecurityException would happen when "JFR.configure dumppath=..." with security manager because the exception says `access denied ("java.io.FilePermission" "." "write")` - it is caused by security constraint.
> 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?
This behavior is request by @mgronlun in https://github.com/openjdk/jdk/pull/5019#issuecomment-912619347 . We need to resolve the path `setDumpPath` to keep original behavior (before JDK-8271949).
> I'm not sure we should use user.home at all. Shouldn't the default path be where the JVM process started?
I think you mean current work directory ( `/proc/self/cwd` in Linux). It is not home directory. So I set `.` to `DEFAULT_DUMP_PATH` as default.
(I removed `USER_HOME` from SecuritySupport in JDK-8271949)
> 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.
`null` might be a solution for default value, but we cannot resolve this problem when relative path is passed to `dumppath`. We need to resolve it at first, otherwise we will see SecurityException again.
We can fix as you said if we can ignore original behavior (path resolution).
-------------
PR: https://git.openjdk.java.net/jdk/pull/5984
More information about the hotspot-jfr-dev
mailing list