# Make \`cargo install\` a \`sudo\` operation

**URL:** <https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532>\
**Category:** cargo\
**Created:** [September 13, 2024, 11:42am UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532 "2024-09-13T11:42:39Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![amab8901](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/amab8901/32/11244_2.png) [@amab8901](https://internals.rust-lang.org/u/amab8901)\
**Post date:** [September 13, 2024, 11:42am UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/1 "2024-09-13T11:42:39Z")

</div>

When we install something via `apt` or `pacman`, etc, we have to use `sudo` for security reasons, because otherwise a hacker might be free to install malware. But this is not a problem for the hacker, because they can just run `cargo install malware123` to install programs written in Rust that emulate the behavior of programs that can only be run in the `sudo` user, but these emulator programs installed via `cargo install` could be run in normal user (i.e. non-root). Thus the entire `sudo` protection get circumvented by the hacker using `cargo install`.

To fix this cybersecurity vulnerability, I propose that we make `cargo install` a sudo operation by default, so that the user has to type the `sudo` password to run this command.

---

<div class="post-metadata">

**Author:** ![Vorpal](https://avatars.discourse-cdn.com/v4/letter/v/aca169/32.png) [@Vorpal](https://internals.rust-lang.org/u/Vorpal)\
**Post date:** [September 13, 2024, 11:52am UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/2 "2024-09-13T11:52:51Z")

</div>

This makes no sense, as cargo install installs per user. It is not a global install. In fact, running cargo install as root makes it less secure than as a normal user, since it would then have access to super user access when building packages.

You can use many many different ways to download and run programs as a normal user. Cargo install is not a security barrier. Just like npm or pip or wget aren't security barriers.

In conclusion I believe you have an incorrect mental model of computer security. What would actually improve security is installing and running software with reduced privileges (sandboxing).

---

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [September 13, 2024, 5:18pm UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/3 "2024-09-13T17:18:20Z")

</div>

To restate a bit, the reason Linux package managers require `sudo` is that they're installing software at the system level. What `cargo install` does is install at a user level and is closer to `curl | sh` installation. If a malicious actor has access to your user shell, they don't need a programming language to inject their payload, they just need `curl | sh`. And likely that's how they'll grab it, since that can work on a greater percentage of machines.

---

<div class="post-metadata">

**Author:** ![workingjubilee](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/workingjubilee/32/7992_2.png) [@workingjubilee](https://internals.rust-lang.org/u/workingjubilee)\
**Post date:** [September 20, 2024, 8:49pm UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/5 "2024-09-20T20:49:21Z")

</div>

the only way to improve cybersecurity for `cargo install` specifically (and not builds in general, e.g. sandboxing) is probably either the usage of lockfiles or removing the subcommand permanently from cargo.

---

<div class="post-metadata">

**Author:** ![jjpe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jjpe/32/9779_2.png) [@jjpe](https://internals.rust-lang.org/u/jjpe)\
**Post date:** [September 20, 2024, 9:19pm UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/6 "2024-09-20T21:19:11Z")

</div>

> [@workingjubilee](#):
>
> removing the subcommand permanently from cargo.

This is undesirable and, if backwards-compatibility is taken as seriously as generally is the case for Rust, not even feasible.

Take diesel as an example. Its CLI application is an integral part of using the library effectively (eg. to perform migrations) and so without a way to install that CLI app, diesel functionally breaks on stable. That is, you can add the library as a dependency to your rust crate, and it'll compile, but managing the backing database will be so onerous as to practically be useless. That's because it would then literally be easier to either use another programming language (and the same sql DB) or just use another DB altogether.

> [@CAD97](#):
>
> they don't need a programming language to inject their payload, they just need `curl | sh`

This is pretty pedantic so feel free to ignore it, but technically `sh` is a Turing-complete programming language. Just not one anyone would want to build anything significant in, for a long, long list of reasons 🙂

---

<div class="post-metadata">

**Author:** ![workingjubilee](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/workingjubilee/32/7992_2.png) [@workingjubilee](https://internals.rust-lang.org/u/workingjubilee)\
**Post date:** [September 20, 2024, 9:31pm UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/7 "2024-09-20T21:31:05Z")

</div>

> This is pretty pedantic so feel free to ignore it, but technically `sh` is a Turing-complete programming language. Just not one anyone would want to build anything significant in, for a long, long list of reasons 🙂

don't tell [Linus Torvalds](https://en.wikipedia.org/wiki/Git) about that,,,

---

<div class="post-metadata">

**Author:** ![pitaj](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pitaj/32/11262_2.png) [@pitaj](https://internals.rust-lang.org/u/pitaj)\
**Post date:** [September 20, 2024, 11:08pm UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/8 "2024-09-20T23:08:41Z")

</div>

One thing that could help the security of `cargo install` is build sandboxing. Currently all that's necessary to pwn someone is to convince them to `cargo install malware`, because of `build.rs` and proc-macros. If those were sandboxed, it would require actually running the resulting binary to get pwned.

---

<div class="post-metadata">

**Author:** ![jjpe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jjpe/32/9779_2.png) [@jjpe](https://internals.rust-lang.org/u/jjpe)\
**Post date:** [September 21, 2024, 6:33am UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/9 "2024-09-21T06:33:52Z")

</div>

> [@pitaj](#):
>
> If those were sandboxed, it would require actually running the resulting binary to get pwned.

But... Who installs a binary only to aboutface and never run it? At that point I'd just say "don't install the binary either then".

---

<div class="post-metadata">

**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\
**Post date:** [March 15, 2026, 6:34am UTC](https://internals.rust-lang.org/t/make-cargo-install-a-sudo-operation/21532/10 "2026-03-15T06:34:04Z")

</div>

Closed on March 15, 2026, 6:34am UTC

This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.
