PING: RFR: 8225694: Destination option missing in FlightRecorderMXBeanImpl

Erik Gahlin erik.gahlin at oracle.com
Mon Oct 7 11:50:27 UTC 2019


Looks good.

Do you want me to sponsor your fix?

Thanks
Erik

> Hi Erik,
>
> Thank you for reviewing again.
>
> I improved focusing on checking the destination and calling setter for 
> destination.
> How about this fix?
>
> JBS https://bugs.openjdk.java.net/browse/JDK-8225694
> webrev http://cr.openjdk.java.net/~cito/JDK-8225694/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ecito/JDK-8225694/webrev.02/>
>
> This fix passed test-tier1 and test/jdk/jdk/jfr.
>
> Regards,
> Chihiro
>
>
> 2019年10月2日(水) 23:28 Erik Gahlin <erik.gahlin at oracle.com 
> <mailto:erik.gahlin at oracle.com>>:
>
>     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