rustup configure an insecure PATH by default.

[sha0coder]

Problem

Configuring the cargo path in the first section of the $PATH creates an extra insecurity on the system, as the comment says it's overriding the system binaries.
It would be more secure to put the "$HOME/.cargo/bin" at last section of the $PATH.

.cargo$ cat env
#!/bin/sh
# rustup shell setup
# affix colons on either side of $PATH to simplify matching
case ":${PATH}:" in
    *:"$HOME/.cargo/bin":*)
        ;;
    *)
        # Prepending path in case a system-installed rustc needs to be overridden
        export PATH="$HOME/.cargo/bin:$PATH"
        ;;
esac

This gives to a local attacker the possibility of overriding sudo or other binaries to get user password or root access.
For sure having access to the account there are other attack vectors, but this open an extra attack vector.

Steps

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Possible Solution(s)

export PATH="$PATH:$HOME/.cargo/bin"

Notes

No response

Rustup version

rustup 1.24.3 (ce5817a94 2021-05-31)                                                                      
info: This is the version for the rustup toolchain manager, not the rustc compiler.                       
info: The currently active `rustc` version is `rustc 1.56.1 (59eed8a2a 2021-11-01)`

Installed toolchains

Default host: x86_64-unknown-linux-gnu                                                                    
rustup home:  /home/sha0/.rustup                                                                          
                                                                                                          
stable-x86_64-unknown-linux-gnu (default)                                                                 
rustc 1.56.1 (59eed8a2a 2021-11-01)

[rbtcollins]

It is true that the current setup permits shadowing distro included binaries, particularly as a side effect of 'cargo install ...'. However for rustup this is a feature, because rustup should still work even if the distro has included cargo, rustc etc in their system packages.

Thus I don't think there is room to do what you suggest while still meeting our primary use case. An alternative way to mitigate shadowing would be for there to be two path entries, one for rustups proxies, and one for cargo installed programs, and that second one could be placed at the rear of the path. We could do that but would need a volunteer to work on it.

[asukaminato0721]

I check the position, seems that by default rustup and cargo installed at the same place, so maybe need to work on that.

ref https://stackoverflow.com/questions/46739842/where-does-rustup-install-itself-to

[rami3l]

I check the position, seems that by default rustup and cargo installed at the same place, so maybe need to work on that.

ref https://stackoverflow.com/questions/46739842/where-does-rustup-install-itself-to

As mentioned in https://stackoverflow.com/a/67095192, $RUSTUP_HOME (instead of $CARGO_HOME) is the installation directory of rustup; we merely put some shortcuts in $CARGO_HOME for convenience.

I believe our policy has remained unchanged over the years: we assume you have direct control over these two directories. If not, you should set them to places you currently directly control.

cc @weihanglo @epage for potential comments on your plan of potentially splitting $CARGO_HOME

[sha0coder]

The problem is not storing binaries on the home folder, the problem is the order of elements in $PATH ***@***.*** ~ [127]> echo $PATH /home/sha0/.cargo/bin /usr/local/bin /usr/bin /bin /usr/games This allows an attacker to override the system binaries,it's not a serious issue, but ideally the .cargo/bin should be the last element on path. If a package deployed an "ls", when the user types "ls" it will be executed the deployed one. The only problem of fixing this, is that the system installed cargo will override the home installed cargo in the case of two cargo binaries exist. regards. El jue, 23 ene 2025 a las 2:12, rami3l ***@***.***>) escribió:

…

I check the position, seems that by default rustup and cargo installed at the same place, so maybe need to work on that. ref https://stackoverflow.com/questions/46739842/where-does-rustup-install-itself-to As mentioned in https://stackoverflow.com/a/67095192, $RUSTUP_HOME (instead of $CARGO_HOME) is the installation directory of rustup; we merely put some shortcuts in $CARGO_HOME for convenience. I believe our policy has remained unchanged over the years: we assume you have direct control over these two directories. — Reply to this email directly, view it on GitHub <#2922 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAK5QQRXUZFQK3YBJO44RT32MA6WVAVCNFSM6AAAAABVU6QGFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGYZTGOJQGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ChrisDenton]

The only problem of fixing this, is that the system installed cargo will override the home installed cargo in the case of two cargo binaries exist.

That would be a serious problem for many.

[weihanglo]

An alternative way to mitigate shadowing would be for there to be two path entries, one for rustups proxies, and one for cargo installed programs, and that second one could be placed at the rear of the path.

This has been brought up in the Pre-RFC of splitting CARGO_HOME. We tend to have a separate CARGO_BIN_HOME. The unresolved part is whether RUSTUP has a separate RUSTUP binary/proxy directory and how that would work.