Add new inherit_handles flag to CommandExt trait

[michaelvanstraten]

This PR adds a new flag to the CommandExt trait to set whether to inherit the handles of the calling process ([ref][1]).

This is necessary when, for example, spawning a process with a pseudoconsole attached.

r? @ChrisDenton

ACP: rust-lang/libs-team#264
[1]: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

GITHUB_ACTION=__run_7
GITHUB_ACTIONS=true
GITHUB_ACTION_REF=
GITHUB_ACTION_REPOSITORY=
GITHUB_ACTOR=michaelvanstraten
GITHUB_API_URL=https://api.github.com
GITHUB_BASE_REF=master
GITHUB_ENV=/home/runner/work/_temp/_runner_file_commands/set_env_95a84762-0ce6-46fd-8ec8-7fec7a2a6980
GITHUB_EVENT_NAME=pull_request
GITHUB_EVENT_NAME=pull_request
GITHUB_EVENT_PATH=/home/runner/work/_temp/_github_workflow/event.json
GITHUB_GRAPHQL_URL=https://api.github.com/graphql
GITHUB_HEAD_REF=set_inherit_handles
GITHUB_JOB=pr
GITHUB_PATH=/home/runner/work/_temp/_runner_file_commands/add_path_95a84762-0ce6-46fd-8ec8-7fec7a2a6980
GITHUB_REF=refs/pull/115501/merge
GITHUB_REF_NAME=115501/merge
GITHUB_REF_PROTECTED=false
---
GITHUB_SERVER_URL=https://github.com
GITHUB_SHA=fc029cc3fa60716113328636886057582cfea2bf
GITHUB_STATE=/home/runner/work/_temp/_runner_file_commands/save_state_95a84762-0ce6-46fd-8ec8-7fec7a2a6980
GITHUB_STEP_SUMMARY=/home/runner/work/_temp/_runner_file_commands/step_summary_95a84762-0ce6-46fd-8ec8-7fec7a2a6980
GITHUB_TRIGGERING_ACTOR=michaelvanstraten
GITHUB_WORKFLOW_REF=rust-lang/rust/.github/workflows/ci.yml@refs/pull/115501/merge
GITHUB_WORKFLOW_SHA=fc029cc3fa60716113328636886057582cfea2bf
GITHUB_WORKSPACE=/home/runner/work/rust/rust
GOROOT_1_18_X64=/opt/hostedtoolcache/go/1.18.10/x64
---
    Checking object v0.32.0
    Checking hashbrown v0.14.0
    Checking miniz_oxide v0.7.1
    Checking addr2line v0.21.0
error[E0545]: `issue` must be a non-zero numeric string or "none"
   --> library/std/src/os/windows/process.rs:264:72
    |
264 |     #[unstable(feature = "windows_process_extensions_inherit_handles", issue = "")]
    |                                                                                |
    |                                                                                cannot parse integer from empty string

error: method has missing stability attribute
error: method has missing stability attribute
   --> library/std/src/os/windows/process.rs:265:5
    |
265 |     fn inherit_handles(&mut self, inherit_handles: bool) -> &mut process::Command;

For more information about this error, try `rustc --explain E0545`.
error: could not compile `std` (lib) due to 2 previous errors
Build completed unsuccessfully in 0:00:12

[michaelvanstraten]

Should this have a stabilization issue attached to it?

[the8472]

First you should create an API change proposal to see if libs-api wants it.

[michaelvanstraten]

I recently changed the exact same interface and didn't need an ACP, is this really required here?

[the8472]

No, not required

Note that an ACP is not strictly required: you can just go ahead and submit a pull request with an implementation of your proposed API, with the risk of wasted effort if the library team ends up rejecting this feature. However do note that this risk is always present even if an ACP is accepted, as the library team can end up rejecting a feature in the later parts of the stabilization process.

[the8472]

Anyway, does windows have an equivalent to posix_spawn_file_actions_adddup2? I.e. a way to provide a list of descriptors that should be explicitly passed to the child process rather than relying on inheritance flags on handles?

Inheritance is questionable in multi-threaded programs because different command-spawning actions may want to pass different files to the child.

Also, how does one communicate to a child that a specific handle is available? On unix we've run into issues defining IO safety when passing ownership through the environment. Are there better ways to send handles to another process?

This is necessary when, for example, spawning a process with a pseudoconsole attached.

Alternatively, can we limit this to passing a set of well-defined handles?

[ChrisDenton]

This is necessary when, for example, spawning a process with a pseudoconsole attached.

It is not necessary when creating a pseudoconsole to disable handle inheritance. Doing so does however allow us to skip the mutex we currently use.

Anyway, does windows have an equivalent to posix_spawn_file_actions_adddup2? I.e. a way to provide a list of descriptors that should be explicitly passed to the child process rather than relying on inheritance flags on handles?

Yes. You need to set inherit_handles to true and then set the PROC_THREAD_ATTRIBUTE_HANDLE_LIST attribute. Rust should have been doing this from the start, imho, but not sure if we can change it now.

I recently changed the exact same interface and didn't need an ACP, is this really required here?

The reason the previous API change didn't require an ACP was because the change was already accepted under an older system (and I asked privately if this was still OK). A new API would need an ACP.

[michaelvanstraten]

It is not necessary when creating a pseudoconsole to disable handle inheritance. Doing so does however allow us to skip the mutex we currently use.

Do you know why all of them set bInheritHandles to false? I have look at a dozenth reference implementation so far and all do so.

[michaelvanstraten]

Okay I just tested it, indeed not necessary to set bInheritHandles.

Would this still be a useful extension to the CommandExt trait?

[ChrisDenton]

Do you know why all of them set bInheritHandles to false? I have look at a dozenth reference implementation so far and all do so.

The most likely the simplest explanation is "because the example code does". But there are good reasons to disable handle inheritance when it's not needed: inheriting unnecessary handles is pointless and also prevents kernel objects from being cleaned up. In the worst case it may also allow the child process to mess with the handles it inherits, though it would have to find them first.

Would this still be a useful extension to the CommandExt trait?

I think it would for the above reasons.

[michaelvanstraten]

I don't know if windows has the concept of confidential handles but preventing the child from acquiring those handles could improve security of spawning commands.

[michaelvanstraten]

Okay, just found the following list in the windows documentation:

Processes can inherit or duplicate handles to the following types of objects:

• Access Token
• Communications device
• Console input
• Console screen buffer
• Desktop
• Directory
• Event
• File
• File mapping
• Job
• Mailslot
• Mutex
• Pipe
• Process
• Registry key
• Semaphore
• Socket
• Thread
• Timer

[michaelvanstraten]

rust-lang/libs-team#264

[michaelvanstraten]

@ChrisDenton should I message somebody about this in rust internals?

[ChrisDenton]

You don't need to do anything other than be patient 🙂. ACPs are discussed in a weekly meeting (time permitting).

[michaelvanstraten]

ACPs are discussed in a weekly meeting (time permitting).

Sorry, didn't know that.

[bors]

☔ The latest upstream changes (presumably #117285) made this pull request unmergeable. Please resolve the merge conflicts.