Expose SECURITY_ATTRIBUTES parameter of file creation on Windows

[dwattttt]

Proposal

Problem statement

File opening/creation on Windows always uses a default SECURITY_ATTRIBUTES parameter, forcing new file handles to not be inherited by child processes by default, and forcing created files to use a default security descriptor (which defines which identities are able to access the newly created file for what operations).

Motivating examples or use cases

Being unable to set a files security descriptor at creation time forces users who want to restrict access to a file to set the descriptor after creation, creating a window of time where the permissions are not enforced and security guarantees unable to be met. rust-lang/miri#2720 (comment) describes miri needing such an API to support tempfile, and in its absence choosing to not support the operation.

Solution sketch

std::os::windows::fs::OpenOptionsExt would expose a method which accepts SECURITY_ATTRIBUTES, similar to how the other customisable parameters to file opening/creation are exposed. Note the existing attributes method is unrelated to SECURITY_ATTRIBUTES.

There is no existing mechanisms to specify this information present in OpenOptions, so there is no collision/priority to resolve with setting this.

I'm unsure of what the policy is around exposing structured platform-native types in the stdlib; a valid security descriptor can only be created via OS APIs, and providing an invalid one has the potential to violate memory safety (as it can contain internal pointers).

Alternatives

The motivating example describes an attempted workaround; set the security descriptor after file creation. This approach was rejected in miri due to the gap where the required access control is not enforced.

The ability to perform this operation could be provided on crates.io, however doing so would require using a crate to perform file creation when this property is desired on Windows; e.g. miri would need to use this external crate in place of the std lib for performing file creation.

File handle inheritance can be specified after the open/create operation has been performed, and does not motivate this API change.

Links and related work

Description of the basic Windows API for creating/opening a file, which includes using SECURITY_ATTRIBUTES: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea
Description of the (mostly opaque) SECURITY_ATTRIBUTES struct: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa379560(v=vs.85)
The SECURITY_ATTRIBUTES struct via winapi: https://docs.rs/winapi/latest/winapi/um/minwinbase/struct.SECURITY_ATTRIBUTES.html
A C++ example of creating a security descriptor to secure a new registry key: https://learn.microsoft.com/en-us/windows/win32/secauthz/creating-a-security-descriptor-for-a-new-object-in-c--

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[dwattttt]

Apologies, I've just noticed this was already filed under #314