Add argv[0] fallback for current_exe() on Linux when /proc is unavailable

[Ecordonnier]

When /proc/self/exe is not accessible (e.g., in containers with masked /proc, chroot environments, or systemd services with ProtectProc=invisible), current_exe() will now fall back to parsing argv[0] and searching PATH.

This brings the Linux implementation in line with existing Rust stdlib patterns on Fuchsia, Solaris/illumos, and AIX, which also use argv[0] when direct kernel APIs are unavailable.

Fallback strategy:

1. Try /proc/self/exe (fast path, existing behavior)
2. On NotFound error, retrieve argv[0] from env::args()
3. If argv[0] is absolute, use it directly
4. If argv[0] contains '/', resolve it as relative path against getcwd()
5. Otherwise, search PATH for the executable (checking execute permissions)
6. Return NotFound error if executable not found in PATH

This handles all common invocation patterns:

• Absolute path: /usr/bin/program
• Relative path: ./program or ../bin/program
• PATH lookup: program (searches directories in PATH)

This maintains backward compatibility: behavior is unchanged when /proc is accessible.

Fixes #46090

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

[Mark-Simulacrum]

Nominating for libs-api to discuss whether we want this or not. #152269 has some good discussion that is worth reading for that discussion, in particular #152269 (comment).

[Ecordonnier]

Nominating for libs-api to discuss whether we want this or not. #152269 has some good discussion that is worth reading for that discussion, in particular #152269 (comment).

Please also consider #46090 in the discussion. The comments in #152269 support the opinion that the corner-case of /proc not being present doesn't exist, while #46090 shows a real-world example of this corner-case.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[nia-e]

We discussed this in last week's @rust-lang/libs-api meeting and found the possible implications too finnicky, and we'd rather just require /proc to be mounted for this method. A PR to the docs to state this may be helpful, though. Thanks!

[oech3]

Oh no

[Ecordonnier]

We discussed this in last week's @rust-lang/libs-api meeting and found the possible implications too finnicky, and we'd rather just require /proc to be mounted for this method. A PR to the docs to state this may be helpful, though. Thanks!

Can you please give some details about the finnicky implications? Especially considering that the AIX implementation in the same file already does it this way.

[nia-e]

This could be a security concern where current_exe is being invoked e.g. in a SUID binary. If an implementor explicitly is okay with this fallback, argv is exposed through std::env::args

[Ecordonnier]

This could be a security concern where current_exe is being invoked e.g. in a SUID binary. If an implementor explicitly is okay with this fallback, argv is exposed through std::env::args

And this is not a security concern for the platforms like AIX where this behavior is already implemented in the same file?

[Ecordonnier]

This could be a security concern where current_exe is being invoked e.g. in a SUID binary. If an implementor explicitly is okay with this fallback, argv is exposed through std::env::args

What is the security concern with suid? argv[0] being modified?

[the8472]

Tier3 targets do get less attention and have less experience on tap. Maybe it is less secure, or maybe there are mitigating circumstances how argv is populated on AIX, we don't know. Either way T3 targets usually don't directly inform choices for T1 targets.

What is the security concern with suid? argv[0] being modified?

That a less privileged parent can pass arbitrary values as argv0, yes.

[oech3]

Would you consider supporting AT_EXECFN at least on Linux(Android) if hijacked argv[0] is the reason to reject this PR?