Security-wise, I don't think it's a good idea to have a shared directory with other users. Why would you need this? Also, why not use java.nio.file.Files.createTempDirectory() and specify 'surefire-' + the username as prefix?

I don't understand the "writable for all" part of the change either. If the temp directory name is user-specific, why would anyone else need to have write access?

The aim of the original PR was to stop Surefire from bloating the system temp directory by instead having it write into a subdirectory 'surefire'. The subdirectory was only writeable by the user that created it. So Surefire would fail if another user ran tests on the same machine (before reboot or otherwise cleaning up temp). Thus the user suffix is introduced by this PR. As user names may contain characters illegal in directory names, there is a risk, even though small or theoretic, that two users have identically names temp subdirectories. By making the directory writeable for all, this risk is eliminated.
Until very recently Surefire wrote to system temp which by definition is shared by all users and was never a security concern to anyone. This PR leaves this semantic untouched.

Thanks for the explanation.

I understand the rationale now, but what about the scenario that java.io.tmpdir is set to a user-specific location in an otherwise protected area? I still think there should be a difference in scrutiny applied between writing to a destination that is already world-writable by design and explicitly making the destination world-writable.

How about passing the username through URLEncoder#encode instead of removing special characters? That is guaranteed to create a directory name that is collision-free and valid on all file systems. It also handles the issue immediately at the code location where it arises rather than working around it somewhere else in a manner that is not particularly easy to grasp.

If you only want to avoid clashes between multiple users, Files.createTempDirectory("surefire-") would create the unique, collision-free directory for you.

That would bloat the system temp directory again, so it would run counter to the motivation for the original change as described in SUREFIRE-2086.

As @sman-81 said: The aim of the original PR was to stop Surefire from bloating the system temp directory by instead having it create the new directory in a fixed subdirectory of the system temp directory, not the system temp directory itself.

Thanks for your input!
I'll amend and rebase the PR early next week.
Until then: Happy New Year!

I've removed the "writable for all" part. The chance of two similar user names - working on the same machine! - resulting in identical sub directory names is theoretic at best. Having the user name as part of the directory name is helpful to quickly spot one's own directory. We are good leaving this part of the code as-is IMO. I look forward to your feedback.