For thirty years, getting root on Linux has meant sudo. That is changing in two different directions at once. Ubuntu has replaced sudo with sudo-rs, a Rust rewrite, and systemd now ships run0, which gets root through a completely different mechanism. All three are likely to coexist for years, so it is worth understanding how each one works.

If you want the fundamentals of sudo itself first, our sudo guide covers the sudoers file and daily use.

How sudo works: setuid

sudo is a setuid-root binary. The file is owned by root with the SUID bit set, so when any user runs it, the kernel starts it with root’s effective user ID:

ls -l /usr/bin/sudo
# -rwsr-xr-x 1 root root ... /usr/bin/sudo

sudo then checks /etc/sudoers, authenticates you through PAM, and if everything passes, runs your command as root.

The problem with that design is not a specific bug. It is that a setuid program starts running with root privileges inside an environment the unprivileged caller controls: their environment variables, their file descriptors, their resource limits, their current directory, their terminal. Every one of those is an input an attacker can shape, and sudo has to sanitize all of them correctly. Our SUID explainer covers why setuid binaries are a perennial privilege escalation target.

sudo is also large: well over 100,000 lines of C, supporting LDAP-backed rules, session logging and replay, plugins, and many options few people use. The more code runs as root before authentication finishes, the more room there is for bugs, and sudo has had serious ones, including 2021’s Baron Samedit heap overflow that gave root to any local user.

sudo-rs: same design, safer language

sudo-rs keeps sudo’s model: it is still setuid, it still reads /etc/sudoers, and sudo apt update works exactly the same. What changes is the implementation:

• Written in Rust, removing buffer overflows and use-after-free bugs of the kind behind Baron Samedit
• Much smaller, closer in size to OpenBSD’s doas than to sudo, because it deliberately drops rarely used features
• Safer defaults, such as not supporting some environment-preserving options that have historically caused trouble

It is developed by the Trifecta Tech Foundation and Ubuntu adopted it as the default sudo, part of the same effort as Rust coreutils.

What sudo-rs leaves out

sudo-rs supports the sudoers features most people use: user and group rules, NOPASSWD, command aliases, Defaults for common options, and sudoedit. Things it omits or limits include:

• LDAP-based sudoers
• sudo’s plugin system and session I/O logging (sudoreplay)
• Sending mail on failed attempts
• Some of the more obscure Defaults options

If you do not know whether you use any of those, you almost certainly do not. If you manage a fleet with LDAP sudoers or rely on session recording for compliance, keep classic sudo.

sudo --version | head -1
# sudo-rs 0.2.x   or   Sudo version 1.9.x

run0: no setuid at all

run0 was added in systemd 256. Rather than being setuid, it asks systemd to start the command for you:

1. You run run0 command
2. run0 asks the systemd service manager (which already runs as root, PID 1) to start command as a transient service running as root, equivalent to systemd-run
3. systemd asks polkit whether you are allowed. polkit prompts for your password
4. If allowed, systemd starts the command in a fresh, clean environment, attached to a new pseudo-terminal that run0 forwards your input and output through

The key difference: no code runs with root privileges in an environment you control. The privileged process is spawned by PID 1 from a known-clean state, like any other system service. Environment variables, file descriptors, and limits from your shell simply never cross over unless explicitly passed.

run0 systemctl restart nginx
run0 --user=postgres psql
run0                             # interactive root shell

By default run0 also tints your terminal background red while the privileged command runs, a small but effective reminder that you are root.

What run0 does differently in practice

Authorization is polkit, not sudoers. By default, members of the admin group (wheel or sudo) may use it after entering their password. Fine-grained rules such as “this user may restart this one service without a password” need to be written as polkit rules in JavaScript under /etc/polkit-1/rules.d/, which is more powerful but less familiar.

It needs systemd running. It does not work in minimal containers without systemd, in rescue shells, or on non-systemd distributions.

No credential caching by default. sudo remembers that you authenticated for a few minutes. run0 asks each time unless polkit is configured to keep authorization.

It is a service. Because the command runs as a transient unit, it appears in systemctl list-units, its output can land in the journal, and it runs with the unit’s properties. You can even pass sandboxing properties:

run0 --property=ProtectHome=yes some-command

Side by side

	sudo	sudo-rs	run0
Mechanism	setuid binary	setuid binary	Transient systemd service
Language	C	Rust	C (part of systemd)
Authentication	PAM	PAM	polkit (which uses PAM)
Rules	/etc/sudoers	/etc/sudoers (subset)	polkit rules
Credential caching	Yes	Yes	Not by default
Needs systemd	No	No	Yes
Works in scripts	Yes	Yes	Awkward
Default on	Most distros	Ubuntu	Nothing yet (installed with systemd 256+)

Which should you use?

For scripts and automation, use sudo or sudo-rs. Scripts rely on sudoers rules like NOPASSWD for specific commands, on predictable non-interactive behaviour, and on working where systemd is not running. run0’s per-invocation polkit prompt and PTY handling make it awkward here.

For interactive administration, run0 is a genuinely good option on any modern systemd distribution. The clean-environment model is a real security improvement, and the red background is a habit worth having.

For compliance environments with LDAP sudoers or session recording, stay on classic sudo.

If you are on Ubuntu, you already have sudo-rs. The main thing to check is that any unusual sudoers directives you rely on are supported; sudo -l shows how your rules are being interpreted.

Whichever tool you use, the underlying advice from our Linux security best practices guide is the same: grant the narrowest privilege that gets the job done, and prefer running services as their own unprivileged users over giving people root.

Frequently Asked Questions

What is run0?

run0 is a privilege escalation command included with systemd since version 256. Instead of being a setuid binary like sudo, it asks the systemd service manager to start the command as a transient service running as root, after authenticating you through polkit.

What is sudo-rs?

sudo-rs is a reimplementation of sudo in the Rust programming language, developed by the Trifecta Tech Foundation. It reads the same sudoers file and accepts the common sudo options, but leaves out rarely used features to keep the codebase small. Ubuntu uses it by default.

Is run0 more secure than sudo?

It has a smaller attack surface in one important way: it is not setuid, so an unprivileged user never runs privileged code in an environment they control. The command starts from a clean service environment instead. It still depends on polkit and systemd being correct, so it moves trust rather than removing it.

Does run0 use the sudoers file?

No. run0 authorization is decided by polkit rules, not /etc/sudoers. By default members of the administrative group, usually wheel or sudo, are allowed after entering their password. Fine-grained per-command rules like those in sudoers need to be written as polkit rules instead.

Why does my terminal turn red with run0?

run0 tints the terminal background red by default while the privileged command runs, as a visual reminder that you are operating as root. It can be turned off with the —background= option set to an empty value.

Should I replace sudo with run0?

For interactive admin work on a systemd machine, run0 is a reasonable choice. For scripts, automation, and anything relying on detailed sudoers rules such as allowing one user to run one command without a password, sudo or sudo-rs is still the more practical tool.