Fix Files.createTempDir and FileBackedOutputStream under Windows.

[copybara-service]

Fix Files.createTempDir and FileBackedOutputStream under Windows.

Based on some discussions in GitHub, I'm under the impression that Windows would create the temporary directory/file in a secure location even if our call to java.nio.file.Files.createTempDirectory/createTempFile passes no ACL attribute. However, in case we are in an unusual situation (Linux with NFS temporary directory???) in which ACLs are supported but the temporary directory is not a secure location, I've arranged for the file to be created with an ACL that grants permissions only to the current user. I set the user's permissions to the ones that I saw on a file created in the temporary directory under Java's default settings, and I didn't do anything to set the additional permissions I was seeing for administrators. The resulting file's permissions look plausibly correct in the Windows property dialog, if slightly different than what I get when creating a file/directory myself through Explorer.

Fixes #6535

Relates to:

• CVE-2020-8908: Files::createTempDir local information disclosure vulnerability #4011
• Security scan reported problem with com.google.common.io.FileBackedOutputStream #2575
• Consider running CI under Windows #2686 (Yay, we have Windows CI set up!)
• Stop skipping certain tests under Windows #2130

RELNOTES=io: Fixed Files.createTempDir and FileBackedOutputStream under Windows.

[basil]

I tested this successfully on my Windows 10 system by creating a directory with broad permissions, verifying that a different user had access to it, setting TMP to that directory, calling Files.createTempDir, and verifying that the resulting temporary directory had an explicit ACL with more restrictive permissions and that a different user did not have access to it. Nice job!

I also ran a test with TMP set to a directory on a FAT32 filesystem and was surprised that the call to Files.createTempDir succeeded, even though FAT32 does not support ACLs. Looking into the implementation in OpenJDK, I saw that it was using CreateDirectoryW, which is documented as follows:

The target file system must support security on files and directories for this parameter to have an effect. (This is indicated when GetVolumeInformation returns FS_PERSISTENT_ACLS.)

FILE_PERSISTENT_ACLS is documented as follows:

The specified volume preserves and enforces access control lists (ACL). For example, the NTFS file system preserves and enforces ACLs, and the FAT file system does not.

So this all appears to be behaving as documented. I would have hoped for an exception when attempting to set an ACL that the underlying filesystem does not support rather than the requested ACLs being silently ignored, but OpenJDK does not appear to support this.

[cpovirk]

Thank you for all that digging! I agree that an exception would be nice, yet I admit that I'm not enthusiastic about writing some more code in Guava to check whether the ACL was applied and to throw an exception if we find that it was not... :) (That's especially true when we're even further from testing under Windows with a FAT filesystem than we are from testing under Windows at all.) Probably anyone who is sharing a FAT filesystem with untrusted users has bigger problems, anyway?

[basil]

Agreed that the current PR is more than sufficient. This is more of a limitation in OpenJDK which I was merely noting for completeness.