# sudo-rs: a memory safe sudo and su in Rust, and what it changes for daily administration

> sudo-rs reimplements sudo and su in Rust under the Apache-2.0 OR MIT licence. It installs from distro packages on Ubuntu, Arch, Fedora, Debian, Alpine and FreeBSD, but it does not yet cover every feature of Todd Miller's sudo.

**trifectatechfoundation/sudo-rs** — A memory safe implementation of sudo and su.

- Repository: https://github.com/trifectatechfoundation/sudo-rs
- Stars: 4,470 · Forks: 179
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/trifectatechfoundation-sudo-rs

## What sudo-rs replaces, and the class of bug it is aimed at

sudo and su sit in an unusual position: they are setuid programs that parse a configuration file written by administrators, then make authorization decisions that grant root. That makes memory safety bugs in them unusually expensive. sudo-rs is a from-scratch implementation of both commands in Rust, from the Trifecta Tech Foundation, licensed Apache-2.0 OR MIT. The Cargo.toml describes it plainly as "A memory safe implementation of sudo and su."

The intended audience is not the casual user who types sudo once a day. It is the distribution maintainer, the platform engineer or the security team that has to ship a setuid binary and defend that choice. The README states that sudo-rs is targeted at FreeBSD and Linux-based operating systems only, so BSD users outside FreeBSD are out of scope. The project has been audited twice, once for version 0.2.0 in August 2023 and once for version 0.2.8 in August 2025, with reports kept in docs/audit.

There is a second, quieter audience: distributions themselves. Ubuntu 25.10 and 26.04 install and enable sudo-rs by default, and postmarketOS does the same on new installs. If you run either, you are already a sudo-rs user whether or not you chose to be.

## How sudo-rs parses sudoers, resolves PAM and decides to let you in

The data flow is the same shape as original sudo, which is the point: sudo reads a sudoers policy, authenticates through PAM, and executes the command. sudo-rs keeps that contract so existing policies and PAM stacks continue to work. The README notes that sudo-rs will process /etc/sudoers-rs if it exists, and otherwise falls back to /etc/sudoers. That fallback matters on a machine where original sudo is still installed, because both tools then read the same file.

Authentication goes through PAM rather than a private password path. The README is explicit that without a suitable PAM configuration either a "fallback" PAM policy is used or sudo-rs refuses to run because it cannot initialize PAM. This is a hard dependency, not a nicety, and it is the most common way a hand-rolled install breaks.

Rust's role is narrower than the marketing around memory safe rewrites usually implies. The Cargo.toml sets unsafe_op_in_unsafe_fn to deny and warns on undocumented unsafe blocks, and the release profile strips symbols and enables LTO. The Makefile shows that PAM bindings are generated with bindgen against a wrapper header, with the generated file checked in per platform variant and a pam-sys-diff target to detect drift. So the unsafe surface is concentrated in generated FFI bindings, and the project tracks when they change.

## Installing sudo-rs from your distribution and running the first command

The README's recommended path is your package manager. On Arch Linux the package avoids clashing with original sudo by installing differently named commands:

```bash
pacman -S sudo-rs
```

After that you get sudo-rs, sudoedit-rs, visudo-rs and su-rs. On Fedora the equivalent is dnf install sudo-rs, which provides sudo-rs, visudo-rs and su-rs. On Debian 13 (trixie) or later the package is apt-get install sudo-rs, providing sudo-rs and visudo-rs; the README says you can get the usual sudo and visudo names by prepending /usr/lib/cargo/bin to your $PATH.

On Ubuntu 25.10 and 26.04 sudo-rs is already installed and enabled. To see which implementation is active and switch between them, the README gives:

```bash
update-alternatives --config sudo
```

On Alpine the package is in the community repository and installs the sudo, visudo and sudoedit commands:

```bash
apk add sudo-rs
```

The su implementation is packaged separately as sudo-rs-su, because Alpine's BusyBox still provides su. FreeBSD has two flavours: pkg install sudo-rs conflicts with security/sudo, while pkg install sudo-rs-coexist installs the -rs suffixed names alongside it. The README notes the pkg utility needs the 2025Q4 quarterly ports tree or later.

If you build from source instead, the README states the minimum Rust version is 1.85 and that you also need the C development files for PAM (libpam0g-dev on Debian, pam-devel on Fedora). The pre-compiled route is x86-64 Linux only, and the README recommends unpacking into /usr/local so you do not fight your package manager:

```bash
sudo tar -C /usr/local -xvf sudo-0.2.15.tar.gz
```

Before trusting a manual install, confirm that /usr/local/bin and /usr/local/sbin come before /usr/bin and /usr/sbin in your PATH, and run visudo-rs to check that your policy parses.

## The feature gaps that decide whether sudo-rs fits your sudoers file

The README does not claim parity, and says so directly: features you might expect from original sudo may still be unimplemented or not planned. That sentence should be read as the main adoption constraint. If your sudoers file leans on directives that sudo-rs has not implemented, the policy will either be rejected or behave differently, and a rejected policy under a setuid binary is not a failure mode you want to discover during an incident.

The version skew across distributions is the second constraint, and it is sharper than the first because it is invisible at runtime. The README states that the sudo-rs package in Ubuntu 25.10 is based on v0.2.8 with backported fixes, while Ubuntu 26.04 LTS is based on v0.2.13. Debian 13 (trixie) ships something based on release 0.2.5 from April 2025, which the README says is missing sudoedit, NOEXEC: and many other usability and compatibility improvements, though it is current on security patches. The same paragraph reports a packaging bug: su-rs cannot be used on Debian 13 because the setuid flag is not set on it. That is a distribution error rather than a sudo-rs design flaw, but it is the kind of thing you only find by testing su-rs directly.

A third limit is scope. FreeBSD and Linux only. If you are on macOS or OpenBSD, sudo-rs is not an option, and no amount of building from source changes that.

## sudo-rs compared with original sudo and with doas

Original sudo, maintained by Todd Miller, is the reference implementation and the one every sudoers tutorial describes. Its advantage is completeness: every directive, every edge case, decades of hardening. sudo-rs trades that completeness for a smaller trusted computing base written in a language with compile-time memory safety. If you need an obscure sudoers option, original sudo has it and sudo-rs may not. If you want the parser and the setuid logic to be Rust rather than C, the trade goes the other way.

doas is a different answer to the same question. It abandons the sudoers grammar entirely for a short config file with a handful of rules, on the argument that most sudoers files are far more complex than the actual requirement. sudo-rs does not take that route: it keeps the sudoers format and PAM, which is why it can be dropped onto an existing system. The practical difference is migration cost. Moving to sudo-rs is largely a packaging and version exercise, because your policy file stays. Moving to doas means rewriting your authorization rules from scratch.

There is also the coexistence question. On Arch, Fedora, Debian and the FreeBSD coexist flavour, sudo-rs installs under -rs suffixed names so both implementations can live side by side. The README warns that an alias only changes your own invocations and does not affect scripts or other programs that call sudo, which is the trap in the coexistence setup: you may believe you are testing sudo-rs while a cron job is still running original sudo.

## Maintenance, packaging cost and licence terms

The last push to the repository was on 2026-09-01, and the most recent release listed is v0.2.15 from 2026-08-31, preceded by v0.2.14 in June 2026 and v0.2.13 in March 2026. The repository is not archived. That cadence suggests a project still receiving changes, though the README's own framing about unimplemented features is the more useful signal for planning.

Upgrade cost depends almost entirely on how you installed it. Through a distribution package, upgrades follow your normal package cycle, and the README's per-distribution notes suggest the Arch and Fedora packages track upstream closely while Debian stable lags. Through the pre-compiled tarballs, you are responsible for re-running the tar extraction and re-checking PATH precedence. Through a source build, you carry the Rust 1.85 minimum and the PAM development headers as build dependencies.

Licensing is dual: the Cargo.toml declares Apache-2.0 OR MIT, and the repository carries LICENSE-APACHE and LICENSE-MIT. That is permissive and compatible with redistribution in distributions and products. The FreeBSD port is maintained by the project itself, which is worth noting because it means the packaging is not solely dependent on outside volunteers. This is a description of the licence terms, not legal advice; if you are redistributing sudo-rs inside a product, confirm the terms with your own counsel.

## Conclusion

Adopt sudo-rs if you want a memory safe sudo on a supported Linux or FreeBSD system and you can live without the full sudoers feature set; on Ubuntu 25.10 and 26.04 it is already the default. Do not adopt it if you depend on features the FAQ lists as unimplemented, if you are on a platform outside Linux and FreeBSD, or if you need a build newer than the one your distribution ships. Before rolling it out, check the version your package manager provides against the v0.2.15 release, confirm that /etc/sudoers-rs or /etc/sudoers parses under visudo-rs, and verify the setuid bit on su-rs, which the Debian 13 package is documented as missing.

## FAQ

### What are the key differences between sudo and sudo-rs?

sudo-rs is a reimplementation of sudo and su in Rust, described in its Cargo.toml as a memory safe implementation. The README states that features you might expect from original sudo may still be unimplemented or not planned, so the main difference is a smaller, memory safe codebase against a more complete feature set.

### How do you install and use sudo-rs?

Install it from your distribution: pacman -S sudo-rs on Arch, dnf install sudo-rs on Fedora, apt-get install sudo-rs on Debian 13 or later, or apk add sudo-rs on Alpine. On Ubuntu 25.10 and 26.04 it is installed and enabled by default, and update-alternatives --config sudo controls which version is used.

### What is sudo-rs?

It is a safety oriented and memory safe implementation of sudo and su written in Rust, from the Trifecta Tech Foundation, targeted at FreeBSD and Linux-based operating systems only.

### How does sudo-rs differ from doas?

sudo-rs keeps the sudoers policy format and PAM authentication, so an existing policy file can be reused. doas is not covered in the sudo-rs README, so this comparison rests on the fact that sudo-rs preserves the sudo model rather than replacing it with a minimal config format.

### Does sudo-rs work with Ansible?

The README does not document Ansible integration. What it does say is that an alias only changes your own invocations of sudo and not other programs or scripts, so automation that calls sudo directly would need the sudo-rs commands to be the ones resolved on PATH.

## Sources

- [Issues](https://github.com/trifectatechfoundation/sudo-rs/issues)
- [License: Apache-2.0](https://github.com/trifectatechfoundation/sudo-rs/blob/main/LICENSE)
- [README](https://github.com/trifectatechfoundation/sudo-rs/blob/main/README.md)
- [Releases](https://github.com/trifectatechfoundation/sudo-rs/releases)
- [trifectatechfoundation/sudo-rs on GitHub](https://github.com/trifectatechfoundation/sudo-rs)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trifectatechfoundation-sudo-rs