PING: RFR: 8225694: Destination option missing in FlightRecorderMXBeanImpl
Erik Gahlin
erik.gahlin at oracle.com
Wed Oct 2 14:28:48 UTC 2019
Hi,
I think it is fine to use Recording::setDestination(...)
recording.setDestination(Paths.get(destination));
It's only when the destination is read that the path object should not
be returned. I now see that getDestinationOriginalText() is already
implemented.
The verification of the path is the tricky thing. Today nothing is being
done.
Looking at the code, there doesn't seem to be a check in
PlatformingRecording/Recording::setDestination, even though the javadoc
states that "@throws IOException if the path is not writable". Not sure
why, but it is outside the scope of this bug.
Maybe you could add a method checkDestination to PlatformRecording:
public void setDestination(WriteableUserPath userSuppliedPath) throws
IOException {
synchronized (recorder) {
checkSetDestination(userSuppliedPath);
this.destination = userSuppliedPath;
}
}
public void checkSetDestination(WriteableUserPath userSuppliedPath)
throws IOException {
synchronized (recorder) {
if (Utils.isState(getState(), RecordingState.STOPPED,
RecordingState.CLOSED)) {
throw new IllegalStateException("Destination can't be set on a
recording that has been stopped/closed");
}
}
}
and then call it over ManagementSupport::checkSetDestination(...) when
the option is validated.
We can then later improve the validation and make sure it works for both
JMX and ordinary use of setDestination.
Thanks
Erik
> Hi Erik,
>
> Could you review this again, please?
>
> Regards,
> Chihiro
>
> 2019年9月26日(木) 0:57 Chihiro Ito <chiroito107 at gmail.com
> <mailto:chiroito107 at gmail.com>>:
>
> Hi Erik,
>
> Thank you for reviewing and advising.
> I modified it. Could you review this, please?
>
> JBS https://bugs.openjdk.java.net/browse/JDK-8225694
> webrev http://cr.openjdk.java.net/~cito/JDK-8225694/webrev.01/
> <http://cr.openjdk.java.net/%7Ecito/JDK-8225694/webrev.01/>
>
> Regards,
> Chihiro
>
> 2019年9月15日(日) 6:34 Erik Gahlin <erik.gahlin at oracle.com
> <mailto:erik.gahlin at oracle.com>>:
>
> Hi Chihiro.
>
> I noticed that you do.
>
> r.getDestination().toString();
>
> I’m not sure if it safe. A malicious user could implement
> their own version of a Path object and have it execute in the
> context of the MBeanServer thread. I would prefer if you would
> access the PlatformRecording object (see
> PrivateAccess::getPlatformRecording) and use
> WriteableUserPath#getText to get a textual representation of a
> path you can return to getOptions(). You can add a method to
> the class jdk.jfr.internal.managemnet.ManagementSupport, i.e
> getRecordingDestintaion(Recording), where you can tunnel
> things to the jdk.management.jfr module.
>
> Maybe you could also add the message “Not a valid destination”
> to the IAE.
>
> Thanks
> Erik
>
> > On 14 Sep 2019, at 19:06, Chihiro Ito <chiroito107 at gmail.com
> <mailto:chiroito107 at gmail.com>> wrote:
> >
> > Hi,
> >
> > Could you review this tiny change, please?
> >
> > JBS https://bugs.openjdk.java.net/browse/JDK-8225694
> > Webrev
> http://cr.openjdk.java.net/~cito/JDK-8225694/webrev.00/
> <http://cr.openjdk.java.net/%7Ecito/JDK-8225694/webrev.00/>
> >
> > Regards,
> > Chihiro
>
More information about the hotspot-jfr-dev
mailing list