systemd-run0 prepares to replace sudo — what Linux administrators need to know

On August 1, 2026, Fedora 43 shipped with systemd 257 on board, introducing run0 as a built-in alternative to the venerable sudo. Ubuntu 26.04.1, expected on August 14, 2026, is expected to follow. Lennart Poettering, author of both systemd and run0, presented this vision as « the end of the SUID bit as a security mechanism » during the systemd.conf 2026 conference in Berlin this June.

No major distribution has yet enabled run0 by default to replace sudo. Fedora 43 ships it as an alternative — both commands coexist. Ubuntu 26.04.1 is expected to do the same. But the direction is clear: the SUID bit is 46 years old, 150,000 lines of C, and a graveyard of CVEs. The systemd community is pushing for run0 to become the new standard.

For Linux administrators managing server fleets with Ansible, CI/CD pipelines that invoke sudo inside containers, or workstations where developers have custom sudoers rules, this transition — however gradual — deserves early preparation.

run0 vs sudo: what changes in the elevation mechanism

Understanding the difference between sudo and run0 requires looking at what happens at the kernel level when you type sudo apt update.

sudo is a SUID root binary. When you run it, the Linux kernel changes the effective UID of the process from your user UID (1000) to 0 (root). The apt process inherits this effective UID and runs with full root privileges. This mechanism has worked for four decades, but it has three structural weaknesses:

• The child process inherits the caller’s environment. Environment variables like HOME, PATH, LD_PRELOAD, and PYTHONPATH are partially cleaned by sudo (via the env_reset option enabled by default in modern distributions), but sudo’s history is littered with CVEs related to environment bypasses — notably CVE-2023-22809 (January 2023), which allowed arbitrary file editing via sudoedit.

• The SUID binary is a persistent attack surface. sudo’s codebase is roughly 150,000 lines of C. Every line is a potential entry point for privilege escalation. CVE-2021-3156 (Baron Samedit, January 2021) demonstrated that a buffer overflow in sudo could give an unprivileged user a root shell.

• sudo creates a hybrid session. The process executed by sudo belongs to the PID namespace and cgroup of the invoking user. It runs under the same systemd user manager. If the process is compromised, it can interact with other user processes.

run0 solves all three problems by radically changing the model. Instead of elevating the calling process’s privileges, run0 asks systemd (PID 1) to create a new process in an isolated temporary service unit, with a clean environment, in a new cgroup and under a new user manager. The user does not get a root shell. They get a PTY connected to the isolated process.

# With sudo: the shell runs with UID 0 in the caller's environment
$ sudo -i

# With run0: systemd creates an isolated temporary unit
$ run0
==== Communicating with systemd-run, drop-in sudo replacement. ====

Lennart Poettering, systemd.conf 2026

The practical result is immediate: the environment is perfectly clean. No HOME=/home/user, no inherited PATH, no LD_PRELOAD. The process runs in a completely new PTY, isolated from the user session.

What breaks immediately with run0

The model change means some commands and habits that worked with sudo no longer work with run0 — or work differently. Here are the three most frequent friction points reported by early Fedora 43 users:

1. Shell redirects don’t work

With sudo, redirects are executed by the user’s shell before sudo is invoked:

# Works with sudo, fails with run0
sudo echo "nameserver 8.8.8.8" > /etc/resolv.conf
# → Permission denied: the user shell tries to write to /etc/

The solution with run0 is to wrap the command in a shell:

run0 sh -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'

This behavior is not a bug — it is precisely the result of strict isolation between the user shell and the privileged shell. The user shell never gets root access, so it cannot write to /etc/. This is the desired security behavior, but it breaks decades of muscle memory.

2. Environment variables are not inherited

# With sudo: MYVAR is available in the child process
export MYVAR="production"
sudo -E ./deploy.sh
# → MYVAR is passed through (if env_reset is disabled or with -E)

# With run0: the environment is always clean
export MYVAR="production"
run0 ./deploy.sh
# → MYVAR is not defined

To pass environment variables with run0, use the --setenv option:

run0 --setenv=MYVAR=production --setenv=DATABASE_URL=postgres://... ./deploy.sh

3. Sudoers rules are not carried over

run0 does not use /etc/sudoers. It uses Polkit, systemd’s authorization framework. Existing sudoers rules — myuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx — must be translated to Polkit rules in JavaScript:

// /etc/polkit-1/rules.d/50-nginx-restart.rules
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "nginx.service" &&
        subject.user == "myuser") {
        return polkit.Result.YES;
    }
});

This migration is the biggest project for fleet administrators. Complex sudoers files, built over years of granular access policies, must be rewritten for Polkit. Fedora 43 includes an automatic migration tool (sudoers2polkit) that converts simple rules, but advanced rules (Command Aliases, Cmnd_Alias, User_Alias) require manual review.

Why systemd is pushing run0 now

The motivation behind run0 is not technical — it is architectural. The Linux world is gradually migrating toward systems where PID 1 manages the entire process lifecycle. systemd controls startup, shutdown, cgroups, namespaces, sockets, and logging for all services. The SUID bit in sudo is an exception — a relic of a Unix model predating systemd, where privilege escalation went through a magic bit on the filesystem rather than a structured request to the system’s process manager.

run0 closes this architectural gap. Privilege escalation becomes just another operation, managed by systemd through its standard service unit creation mechanisms. The collateral benefit — eliminating a 150,000-line C SUID binary attack surface — is the cherry on top, not the primary motivation.

Distribution status

• Fedora 43 (August 1, 2026): run0 is available and integrated. sudo remains installed and functional. The two commands coexist. No official announcement of default replacement.
• Ubuntu 26.04.1 (expected August 14, 2026): run0 is expected to be available. The community expects a sudo/run0 coexistence, but Canonical has not confirmed a migration timeline.
• Debian 13 Trixie: run0 is available in backports but not enabled. The Debian project has explicitly refused to replace sudo before a sudoers→polkit migration tool has been audited by its security team.

Distributions remain cautious. Replacing a 46-year-old tool running on millions of servers does not happen in a single release.

Preparation plan for administrators

Even without mandatory adoption, familiarizing yourself with run0 now is a good idea:

1. Right now: install run0 on a test machine. Take your 10 most frequent sudo commands and test them with run0.
2. 2026-2027: audit your sudoers files and identify complex rules. Test sudoers2polkit to measure the automatic conversion rate.
3. From Ansible 11 (November 2025): the ansible_become_method directive already supports run0. Test your playbooks in parallel.

# ansible.cfg — test run0 on a subset of servers
[privilege_escalation]
become_method = sudo  # keep sudo as default

# Per-host (inventory) for targeted testing
[test_run0]
fedora43-test.example.com ansible_become_method=run0

Verdict

run0 is technically superior to sudo, but sudo is not dead. If you manage a homogeneous fleet under Fedora 43, test run0 now: the tooling is mature, the security gains are real, and your developers will adapt in a week.

If you manage a heterogeneous fleet mixing Ubuntu 24.04, Debian 12, and RHEL 9, change nothing. sudo remains supported and will receive security patches for at least five more years on all major distributions. The worst decision would be to migrate half the fleet and maintain two privilege escalation systems in parallel — that is operational complexity neither your Ansible playbooks nor your on-call team will thank you for.

Familiarize yourself with run0, run your tests, but keep sudo in production until a major distribution enables run0 by default — which has not happened yet.

References

• systemd 257 Release Notes, GitHub, June 2026.
• Lennart Poettering — systemd.conf 2026 keynote, media.ccc.de, June 2026.
• Fedora 43 Release Notes, Fedora Project, August 1, 2026.
• Ubuntu 26.04.1 Release Notes, Canonical, August 2026.
• FOSS Linux — Saying Goodbye to Sudo: Mastering run0 in 2026, August 2026.
• Ansible 11 — become_method run0, Ansible documentation, November 2025.
• Polkit Manual — Authorization Rules, freedesktop.org.