Remove hard links from env::current_exe security example

[mgeisler]

The security example shows that env::current_exe will return the path used when the program was started. This is not really surprising considering how hard links work: after ln foo bar, the two files are equivalent. It is not the case that bar is a “link” to foo, nor is foo a link to bar. They are simply two names for the same underlying data.

The security vulnerability linked to seems to be different: there an attacker would start a SUID binary from a directory under the control of the attacker. The binary would respawn itself by executing the program found at /proc/self/exe (which the attacker can control). This is a real problem. In my opinion, the example given here doesn’t really show the same problem, it just shows a misunderstanding of what hard links are.

I looked through the history a bit and found that the example was introduced in #33526. That PR actually has two commits, and the first (8478d48) explains the race condition at the root of the linked security vulnerability. The second commit proceeds to replace the explanation with the example we have today.

This commit reverts most of the second commit from #33526.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

The security vulnerability linked to seems to be different: there an attacker would start a SUID binary from a directory under the control of the attacker. The binary would respawn itself by executing the program found at /proc/self/exe (which the attacker can control). This is a real problem. In my opinion, the example given here doesn’t really show the same problem, it just shows a misunderstanding of what hard links are.

I think the hard link example sort of illustrates (at least IMO) that the directory being under control isn't necessary -- you can start the binary in an arbitrary place. This means that for example assuming current_exe().with_filename(config) to discover configuration at runtime has security implications.

But I think the specificity of the example hurt more than helped -- and the new text does a slightly better job at explaining the problem.

@bors r+ rollup

[bors]

📌 Commit 9a1dc2a has been approved by Mark-Simulacrum

[mgeisler]

The security vulnerability linked to seems to be different: there an attacker would start a SUID binary from a directory under the control of the attacker. The binary would respawn itself by executing the program found at /proc/self/exe (which the attacker can control). This is a real problem. In my opinion, the example given here doesn’t really show the same problem, it just shows a misunderstanding of what hard links are.

I think the hard link example sort of illustrates (at least IMO) that the directory being under control isn't necessary -- you can start the binary in an arbitrary place. This means that for example assuming current_exe().with_filename(config) to discover configuration at runtime has security implications.

Good point and yeah, it does demonstrate it in an indirect way.

But I think the specificity of the example hurt more than helped -- and the new text does a slightly better job at explaining the problem.

Thanks, I think that's a good way to put it.