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

Yasumasa Suenaga ysuenaga at openjdk.java.net
Mon Oct 18 07:08:55 UTC 2021


On Mon, 18 Oct 2021 02:46:24 GMT, Erik Gahlin <egahlin 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 would expect jcmd users to be informed (in their client) if there is a problem, similar to other incorrect options with JFR.configure. Logging in JVM process seems incorrect (and also the log tag set, JFR_DCMD seems more appropriate).

I can change log tag to JFR_DCMD, but it is difficult to propagate warnings to jcmd user because the problem can happen in out of jcmd like this case (remote recording). In addition, similar logs would happen in other places (e.g. `PlatformRecorder::destroy`). I think it would be better to fix in other JBS ticket if we should fix.

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

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


More information about the hotspot-jfr-dev mailing list