Prevent mutating the global environment pointer in `CommandExt::exec` and opt to use execve and resolve path manually by asder8215 · Pull Request #157144 · rust-lang/rust

asder8215 · 2026-05-30T07:04:28Z

This PR fixes the bug described in #156951 where CommandExt::exec mutating the global environment pointer could cause correctness issue with concurrent exec calls (also this function holds an environment read lock, so it shouldn't cause any writes to the global environment pointer anyways). We do everything within CommandExt::exec via execve than execvp, which means we have to resolve the path manually.

I took reference to what was done in an archived (Feb 2026) upstream mirror of glibc's execvp and execvpe. I also took reference to #55359 on how they implemented the concerned portion of CommandExt::exec with execve. There's also this OpenBSD libc implementation of execvpe that I saw, but I didn't deeply take a look at this one and saw how it differ.

Other than that, I'm unsure how to handle the error ETIMEOUT/TimedOut as glibc breaks parsing through the PATH environment variable value and returns the error while #55359 continues parsing.

Let me know if you also want me to put some of execve code in a helper function or refactor it in other ways.

…nd opt to use execve and resolve path manually

rustbot · 2026-05-30T07:04:33Z

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ChrisDenton, libs
@ChrisDenton, libs expanded to 8 candidates
Random selection from Mark-Simulacrum, joboet

rust-log-analyzer · 2026-05-30T07:41:39Z

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

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

[RUSTC-TIMING] object test:false 8.665
error[E0425]: cannot find value `NAME_MAX` in crate `libc`
   --> library/std/src/sys/process/unix/unix.rs:420:50
    |
420 |         else if file_as_bytes.len() - 1 >= libc::NAME_MAX as usize {
    |                                                  ^^^^^^^^ not found in `libc`

For more information about this error, try `rustc --explain E0425`.
[RUSTC-TIMING] std test:false 4.545
error: could not compile `std` (lib) due to 1 previous error

joboet

I highly recommend having a look at the POSIX specification – GNU/Linux mostly follows that, but the specification sometimes leaves some things unspecified and we should be careful not to break those.

Also, this is currently unsound, we cannot perform any memory allocation in do_exec, since it's called after fork for the standard spawn path. You probably need to preallocate some memory when creating the Command (or when setting certain parameters).

View changes since this review

joboet · 2026-05-30T12:09:43Z

+            return Err(io::Error::from_raw_os_error(libc::ENOENT));
+        }
+        // Path searching does not occur when our file starts with a `/`
+        else if file_as_bytes.starts_with(&[b'/']) {


This mismatches the POSIX specification, the file is interpreted as path if it contains a slash character in any place.

Also, I'd move this check to before all the path stuff, that's redundant if this path is taken.

joboet · 2026-05-30T12:14:32Z

+        let argv = self.get_argv();
+        let parent_path = crate::env::var("PATH")
+            .map(|var| CString::new(var))
+            .unwrap_or(CString::new("/bin:/usr/bin"))?;


I don't really like this duplication of the default path. Can you factor this differently?

joboet · 2026-05-30T12:15:49Z

+            return Err(io::Error::from_raw_os_error(libc::ENAMETOOLONG));
+        } else {
+            let mut got_perm_denied = None;
+            while paths != &[b'\0'] {


This whole logic is equivalent to split_paths

joboet · 2026-05-30T12:17:43Z

+                    None => c"/bin:/usr/bin".to_bytes_with_nul(),
+                }
+            }
+            None => parent_path.as_bytes_with_nul(),


I recommend moving the environment variable lookup here so that it's only performed when actually needed.

joboet · 2026-05-30T12:21:25Z

+                    // Remove "PATH="
+                    Some(p) => &p.to_bytes_with_nul()[5..],
+                    // Falls back to this if PATH environment variable couldn't be found
+                    None => c"/bin:/usr/bin".to_bytes_with_nul(),


This default is incorrect. E.g. on GNU/Linux you should use confstr(_CS_PATH) (see sys/pal/unix/conf.rs for a safe wrapper). _CS_PATH is probably the right choice in general, but might not be enough to match execvp (POSIX specifies that the fallback is "implementation defined").

joboet · 2026-05-30T12:29:31Z

+                binary_path.extend_from_slice(dir);
+                binary_path.push(b'/');
+                binary_path.extend_from_slice(file.to_bytes());
+                let cstr_path = CString::new(binary_path)?;


This searches for nuls even though none can be present (both dir and file come from a CStr).

joboet · 2026-05-30T12:36:37Z

+        let parent_path = crate::env::var("PATH")
+            .map(|var| CString::new(var))
+            .unwrap_or(CString::new("/bin:/usr/bin"))?;
+        let envp = maybe_envp.map(|envp| envp.as_ptr()).unwrap_or(*sys::env::environ());


It's probably a good idea to hold the environment read lock if inheriting the environment from the parent.

Isn't the environment read lock always held before do_exec is called?

do_exec (as far as I can tell) is called from Command::spawn & Command:exec, which I see that they invoke sys::env::read_lock before calling do_exec

Oh right, fair enough. That means that the parent PATH lookup cannot use env::var_os since RwLock does not allow recursive read locks (you shouldn't use it anyway as it allocates).

That means that the parent PATH lookup cannot use env::var_os since RwLock does not allow recursive read locks (you shouldn't use it anyway as it allocates).

That's fine, I think I can use libc::getenv(key.as_ptr()) as *const libc::c_char and CStr::from_ptr to do the PATH lookup (this is what getenv does underneath the hood).

joboet · 2026-05-30T12:39:48Z

+        // Ensure that our given file does not exceed the limit set by NAME_MAX
+        // Note: `file` is a CStr, so it should be guaranteed to have a nul terminated
+        // byte (hence no underflow occurs here)
+        else if file_as_bytes.len() - 1 >= libc::NAME_MAX as usize {
+            return Err(io::Error::from_raw_os_error(libc::ENAMETOOLONG));


I'd just leave this check to execve...

joboet · 2026-05-30T12:43:00Z

+                    && err == libc::ENOEXEC
+                {
+                    let mut new_argv = CStringArray::with_capacity(argv.len() + 2);
+                    new_argv.push(CString::new("/bin/sh")?);


This path is implementation defined – though I imagine it's correct for nearly all platforms.

rustbot · 2026-05-30T12:50:15Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Prevent mutating the global environment pointer in CommandExt::exec a…

50dded6

…nd opt to use execve and resolve path manually

rustbot assigned joboet May 30, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 30, 2026

joboet requested changes May 30, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 30, 2026

Uh oh!

Conversation

asder8215 commented May 30, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented May 30, 2026

Uh oh!

rust-log-analyzer commented May 30, 2026

Uh oh!

joboet left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asder8215 May 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented May 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

asder8215 commented May 30, 2026 •

edited by rustbot

Loading

joboet left a comment •

edited

Loading

asder8215 May 30, 2026 •

edited

Loading