RFR: 8307526: [JFR] Better handling of tampered JFR repository [v2]

[Joakim Nordström]

On Wed, 14 Jun 2023 12:18:28 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Joakim Nordström has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>>  - 8307526: [JFR] Better handling of tampered JFR repository
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/FilePurger.java line 70:
> 
>> 68:                 return true;
>> 69:             }
>> 70:         } catch (IOException e) {
> 
> Looks like there could be a race here. If the file is removed after the exists check, but before the file is deleted, the method may return false incorrectly.

Yes, well spotted. However, does it matter? If this method return false, it means the file will still be in the list of paths to remove, and upon next purge, the SecuritySupport.exists(p) would see the file doesn't exist, and return true. 

I added it because SecuritySupport.delete() might throw an exception (via Files.delete()) if the file doesn't exists, causing non-existent files to be left in the purge list until removeOldest() removes them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14360#discussion_r1230540737