Fixes #46775 -- don't mutate the process's environment in Command::exec by alex · Pull Request #55359 · rust-lang/rust

alex · 2018-10-25T19:48:04Z

Instead, pass the environment to execvpe, so the kernel can apply it directly to the new process. This avoids a use-after-free in the case where exec'ing the new process fails for any reason, as well as a race condition if there are other threads alive during the exec.

Fixes#46775

rust-highfive · 2018-10-25T19:48:07Z

r? @aidanhs

(rust_highfive has picked a reviewer for you, use r? to override)

rust-highfive · 2018-10-25T21:01:18Z

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:1e57ed48:start=1540496989186451903,finish=1540497072419176941,duration=83232725038
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
---
[00:51:15] .................................................................................................... 2200/4951
[00:51:19] .................................................................................................... 2300/4951
[00:51:23] .................................................................................................... 2400/4951
[00:51:26] .................................................................................................... 2500/4951
[00:51:30] .....................................................iiiiiiiii...................................... 2600/4951
[00:51:37] ...ii............................................................................................... 2800/4951
[00:51:40] .................................................................................................... 2900/4951
[00:51:44] ..............................................................................................i..... 3000/4951
[00:51:46] .................................................................................................... 3100/4951
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:04:29] [01:04:29] running 111 tests
[01:04:32] i..ii...iii.......i...i.........i..iii...........i.....i.....ii...i.i.ii..............i...ii..ii.i.. 100/111
[01:04:32] ..iiii.....
[01:04:32] [01:04:32] finished in 3.441
[01:04:32] travis_fold:end:test_codegen
---
travis_time:start:test_run-pass-fulldeps
Check compiletest suite=run-pass-fulldeps mode=run-pass (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:05:50] [01:05:50] running 97 tests
[01:07:47] .................F..........................................test [run-pass] run-pass-fulldeps/myriad-closures.rs has been running for over 60 seconds
[01:09:47] [01:09:47] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:503:22
[01:09:47] [01:09:47] [01:09:47] [01:09:47] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass-fulldeps" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass-fulldeps" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-5.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "5.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:09:47] [01:09:47] [01:09:47] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:09:47] Build completed unsuccessfully in 0:23:15
[01:09:47] Build completed unsuccessfully in 0:23:15
[01:09:47] make: *** [check] Error 1
[01:09:47] Makefile:58: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1d040b80
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:2a4570d6:start=1540501274022974846,finish=1540501274029192790,duration=6217944
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:2e5c7ce9
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:02f2f52e
travis_time:start:02f2f52e
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:26c556f0
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

alex · 2018-10-25T21:02:30Z

I don't see how I could have broken compiletests, with a libstd fix?

kennytm · 2018-10-26T03:37:16Z

The failure in question is https://github.com/rust-lang/rust/blob/master/src/test/run-pass-fulldeps/issue-15149.rs which used Command::new so I believe it is legit.

Details

[01:09:47] ---- [run-pass] run-pass-fulldeps/issue-15149.rs stdout ----
[01:09:47] [01:09:47] error: test run failed!
[01:09:47] status: exit code: 101
[01:09:47] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass-fulldeps/issue-15149/a"
[01:09:47] stdout:
[01:09:47] ------------------------------------------
[01:09:47] [01:09:47] ------------------------------------------
[01:09:47] stderr:
[01:09:47] ------------------------------------------
[01:09:47] thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', libcore/result.rs:1009:5
[01:09:47] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:09:47] [01:09:47] ------------------------------------------
[01:09:47] [01:09:47] thread '[run-pass] run-pass-fulldeps/issue-15149.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3284:9
[01:09:47] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:09:47] [01:09:47] [01:09:47] failures:
[01:09:47] [run-pass] run-pass-fulldeps/issue-15149.rs

alex · 2018-10-26T03:45:46Z

Ooof, this one is a mess. With the previous logic, the env was mutated so the current process's env contained a modified PATH, which was used to lookup the binary. With the new logic, execvpe uses the current process's PATH, not the PATH in envp.

That's a frustrating mess, the only workaround that comes to mind is implementing which ourselves if PATH is in envp, does that make sense? Does anyone see a better workaround?

RalfJung · 2018-10-26T07:11:44Z

TBH I wouldn't even expect the PATH that I set for the new process to have any effect on resolving that process' binary name. That binary resolution is done in the parent process, after all.

alex · 2018-10-26T12:32:01Z

Unfortunately #15149 indicates that this was an intentional decision, so we can't just break it.

RalfJung · 2018-10-26T12:41:52Z

Oh this is so sad :(

So the original Unix implementation used a strange way to change the child's environment (not using execvpe, basically). Sounds mostly like a coincidence to me. Then it was determined that the Windows implementation (which did NOT apply the PATH before searching for the child binary) should be consistent and hence it got some hacky code to parse PATH that has already lead to bugs. And now we have to add the same hack to the Unix implementation... so we end up with all platforms having to carry this hack to get unnatural behavior just because we used to have it on Unix. :(

RalfJung · 2018-10-26T12:42:01Z

Cc @alexcrichton

rust-highfive · 2018-10-27T03:16:24Z

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:10cf1cae:start=1540606730969347602,finish=1540606784905804478,duration=53936456876
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
---
[00:49:25] .................................................................................................... 2200/4957
[00:49:29] .................................................................................................... 2300/4957
[00:49:33] .................................................................................................... 2400/4957
[00:49:37] .................................................................................................... 2500/4957
[00:49:40] .........................................................iiiiiiiii.................................. 2600/4957
[00:49:47] .......ii........................................................................................... 2800/4957
[00:49:49] .................................................................................................... 2900/4957
[00:49:53] ..................................................................................................i. 3000/4957
[00:49:55] .................................................................................................... 3100/4957
---
Check compiletest suite=run-pass mode=run-pass (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:50:48] [00:50:48] running 2869 tests
[00:50:59] .................................................................................................... 100/2869
[00:51:09] .............................................................................i.............F........ 200/2869
[00:51:17] F................................................................................................... 300/2869
[00:51:35] .................................................................................................... 500/2869
[00:51:46] .................................................................................................... 600/2869
[00:51:59] .................................................................................................... 700/2869
[00:52:10] .................................................................................................... 800/2869
---
[00:53:48] .................................................................................................... 1700/2869
[00:53:59] .................................................................................................... 1800/2869
[00:54:09] ...................................................................i................................ 1900/2869
[00:54:20] .....................................i.............................................................. 2000/2869
[00:54:42] ...................................................................................F................ 2100/2869
[00:54:49] ...................................................................................................i 2200/2869
[00:55:18] .............i...................................................................................... 2400/2869
[00:55:33] .................................................................................................... 2500/2869
[00:55:57] .................................................................................................... 2600/2869
[00:56:06] .................................................................................................... 2700/2869
[00:56:06] .................................................................................................... 2700/2869
[00:56:14] .................................................................................................... 2800/2869
e=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "5.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[00:56:23] [00:56:23] [00:56:23] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[00:56:23] Build completed unsuccessfully in 0:11:41
[00:56:23] Build completed unsuccessfully in 0:11:41
[00:56:23] make: *** [check] Error 1
[00:56:23] Makefile:58: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:152cb9b4
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

rust-highfive · 2018-10-27T03:39:14Z

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:1f760674:start=1540610670464263868,finish=1540610723587992701,duration=53123728833
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
---
[00:04:59] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:59] tidy error: /checkout/src/libstd/sys/unix/process/process_unix.rs:294: line longer than 100 chars
[00:05:00] some tidy checks failed
[00:05:00] [00:05:00] [00:05:00] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:05:00] [00:05:00] [00:05:00] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:05:00] Build completed unsuccessfully in 0:00:48
[00:05:00] Build completed unsuccessfully in 0:00:48
[00:05:00] Makefile:79: recipe for target 'tidy' failed
[00:05:00] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0fca592f
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:0d84256a:start=1540611034904924740,finish=1540611034911353419,duration=6428679
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1159c617
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:02169def
travis_time:start:02169def
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:035bde78
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

alexcrichton

Thanks for the fix here! I've got a few comments but they should be pretty easily fixable

alex · 2018-10-30T01:24:09Z

@alexcrichton I think I got 'em both.

alexcrichton · 2018-10-30T17:40:59Z

@bors: r+

Thanks!

bors · 2018-10-30T17:41:02Z

📌 Commit fc770eaed19d1bc488cfa4632889edc107a7d813 has been approved by alexcrichton

alexcrichton · 2018-10-31T18:34:11Z

@bors: p=1

We'll want to be sure to backport this, so raising priority

alexcrichton · 2018-10-31T18:34:32Z

@bors: r+ p=1

er oops, didn't mean to close

bors · 2018-10-31T18:34:34Z

💡 This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: add an appveyor config for aarch64-pc-windows-msvc #54718

[beta] Fixes#46775 -- don't mutate the process's environment in Command::exec This is a backport of the following PRs: * #55359 * #55569 * #55304

[beta] Fixes#46775 -- don't mutate the process's environment in Command::exec This is a backport of the following PRs: * #55359 * #55569 * #55304 * #55661

This commit, after reverting rust-lang#55359, applies a different fix for rust-lang#46775 while also fixing rust-lang#55775. The basic idea was to go back to pre-rust-lang#55359 libstd, and then fixrust-lang#46775 in a way that doesn't expose rust-lang#55775. The issue described in rust-lang#46775 boils down to two problems: * First, the global environment is reset during `exec` but, but if the `exec` call fails then the global environment was a dangling pointer into free'd memory as the block of memory was deallocated when `Command` is dropped. This is fixed in this commit by installing a `Drop` stack object which ensures that the `environ` pointer is preserved on a failing `exec`. * Second, the global environment was accessed in an unsynchronized fashion during `exec`. This was fixed by ensuring that the Rust-specific environment lock is acquired for these system-level operations. Thanks to Alex Gaynor for pioneering the solution here! Closesrust-lang#55775 Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>

std: Synchronize access to global env during `exec` This commit, after reverting #55359, applies a different fix for #46775 while also fixing #55775. The basic idea was to go back to pre-#55359 libstd, and then fix#46775 in a way that doesn't expose #55775. The issue described in #46775 boils down to two problems: * First, the global environment is reset during `exec` but, but if the `exec` call fails then the global environment was a dangling pointer into free'd memory as the block of memory was deallocated when `Command` is dropped. This is fixed in this commit by installing a `Drop` stack object which ensures that the `environ` pointer is preserved on a failing `exec`. * Second, the global environment was accessed in an unsynchronized fashion during `exec`. This was fixed by ensuring that the Rust-specific environment lock is acquired for these system-level operations. Thanks to Alex Gaynor for pioneering the solution here! Closes#55775

This commit, after reverting rust-lang#55359, applies a different fix for rust-lang#46775 while also fixing rust-lang#55775. The basic idea was to go back to pre-rust-lang#55359 libstd, and then fixrust-lang#46775 in a way that doesn't expose rust-lang#55775. The issue described in rust-lang#46775 boils down to two problems: * First, the global environment is reset during `exec` but, but if the `exec` call fails then the global environment was a dangling pointer into free'd memory as the block of memory was deallocated when `Command` is dropped. This is fixed in this commit by installing a `Drop` stack object which ensures that the `environ` pointer is preserved on a failing `exec`. * Second, the global environment was accessed in an unsynchronized fashion during `exec`. This was fixed by ensuring that the Rust-specific environment lock is acquired for these system-level operations. Thanks to Alex Gaynor for pioneering the solution here! Closesrust-lang#55775 Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>

std: Synchronize access to global env during `exec` This commit, after reverting #55359, applies a different fix for #46775 while also fixing #55775. The basic idea was to go back to pre-#55359 libstd, and then fix#46775 in a way that doesn't expose #55775. The issue described in #46775 boils down to two problems: * First, the global environment is reset during `exec` but, but if the `exec` call fails then the global environment was a dangling pointer into free'd memory as the block of memory was deallocated when `Command` is dropped. This is fixed in this commit by installing a `Drop` stack object which ensures that the `environ` pointer is preserved on a failing `exec`. * Second, the global environment was accessed in an unsynchronized fashion during `exec`. This was fixed by ensuring that the Rust-specific environment lock is acquired for these system-level operations. Thanks to Alex Gaynor for pioneering the solution here! Closes#55775

This commit, after reverting rust-lang#55359, applies a different fix for rust-lang#46775 while also fixing rust-lang#55775. The basic idea was to go back to pre-rust-lang#55359 libstd, and then fixrust-lang#46775 in a way that doesn't expose rust-lang#55775. The issue described in rust-lang#46775 boils down to two problems: * First, the global environment is reset during `exec` but, but if the `exec` call fails then the global environment was a dangling pointer into free'd memory as the block of memory was deallocated when `Command` is dropped. This is fixed in this commit by installing a `Drop` stack object which ensures that the `environ` pointer is preserved on a failing `exec`. * Second, the global environment was accessed in an unsynchronized fashion during `exec`. This was fixed by ensuring that the Rust-specific environment lock is acquired for these system-level operations. Thanks to Alex Gaynor for pioneering the solution here! Closesrust-lang#55775 Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>

rust-highfive assigned aidanhs Oct 25, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 25, 2018

alex force-pushed the command-exec-uaf branch from dee48bf to 34ab6a3Compare October 27, 2018 02:17

alex force-pushed the command-exec-uaf branch from 34ab6a3 to 13c6fb7Compare October 27, 2018 03:23

alex force-pushed the command-exec-uaf branch from 13c6fb7 to 1c07f4dCompare October 27, 2018 03:41

alexcrichton reviewed Oct 29, 2018
View reviewed changes

Comment threadsrc/libstd/sys/unix/process/process_unix.rs Outdated
Comment threadsrc/libstd/sys/unix/process/process_unix.rs Outdated

alex force-pushed the command-exec-uaf branch from 1c07f4d to fc770eaCompare October 29, 2018 22:02

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 30, 2018

alexcrichton added beta-nominated Nominated for backporting to the compiler in the beta channel. beta-accepted Accepted for backporting to the compiler in the beta channel. labels Oct 31, 2018

alexcrichton closed this Oct 31, 2018

alexcrichton reopened this Oct 31, 2018

alexcrichton mentioned this pull request Nov 2, 2018
[beta] Fixes #46775 -- don't mutate the process's environment in Command::exec #55611
Merged

alexcrichton added stable-accepted Accepted for backporting to the compiler in the stable channel. and removed stable-accepted Accepted for backporting to the compiler in the stable channel. labels Nov 2, 2018

emilyalbini removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Nov 6, 2018

emilyalbini added stable-accepted Accepted for backporting to the compiler in the stable channel. and removed stable-accepted Accepted for backporting to the compiler in the stable channel. stable-nominated Nominated for backporting to the compiler in the stable channel. labels Nov 7, 2018

bors added a commit that referenced this pull request Nov 7, 2018
Auto merge of#55611- alexcrichton:beta-next, r=alexcrichton
00b9ddb
[beta] Fixes#46775 -- don't mutate the process's environment in Command::exec This is a backport of the following PRs: * #55359 * #55569 * #55304

phansch mentioned this pull request Nov 8, 2018
Regression in Command::exec's PATH resolution #55775
Closed

bors added a commit that referenced this pull request Nov 8, 2018
Auto merge of#55611- alexcrichton:beta-next, r=alexcrichton
bf00632
[beta] Fixes#46775 -- don't mutate the process's environment in Command::exec This is a backport of the following PRs: * #55359 * #55569 * #55304 * #55661

alexcrichton mentioned this pull request Nov 13, 2018
Fixes #55775 -- fixed regression in Command::exec's handling of PATH. #55793
Closed

alexcrichton mentioned this pull request Nov 13, 2018
std: Synchronize access to global env during exec#55939
Merged

tmiasko mentioned this pull request Sep 14, 2020
std::process::Command doesn't follow Unix signal safety in forked child #64718
Open

qwaz mentioned this pull request May 26, 2026
CommandExt::exec writes to the global environment pointer while holding only a read lock #156951
Open

asder8215 mentioned this pull request May 30, 2026
Prevent mutating the global environment pointer in CommandExt::exec and opt to use execve and resolve path manually #157144
Open

Uh oh!

Uh oh!

Conversation

alex commented Oct 25, 2018• edited by RalfJung Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Oct 25, 2018

Uh oh!

rust-highfive commented Oct 25, 2018

Uh oh!

alex commented Oct 25, 2018

Uh oh!

kennytm commented Oct 26, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alex commented Oct 26, 2018

Uh oh!

RalfJung commented Oct 26, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alex commented Oct 26, 2018

Uh oh!

RalfJung commented Oct 26, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented Oct 26, 2018

Uh oh!

rust-highfive commented Oct 27, 2018

Uh oh!

rust-highfive commented Oct 27, 2018

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alex commented Oct 30, 2018

Uh oh!

alexcrichton commented Oct 30, 2018

Uh oh!

bors commented Oct 30, 2018

Uh oh!

alexcrichton commented Oct 31, 2018

Uh oh!

alexcrichton commented Oct 31, 2018

Uh oh!

bors commented Oct 31, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

alex commented Oct 25, 2018•
edited by RalfJung
Loading

kennytm commented Oct 26, 2018•
edited
Loading

RalfJung commented Oct 26, 2018•
edited
Loading

RalfJung commented Oct 26, 2018•
edited
Loading