doas
Execute commands as another user
TLDR
Run a command as root
Run a command as another user
Launch the default shell as root
Parse a configuration file and check if the execution of a command as another user is allowed
Make doas request a password even after it was supplied earlier
SYNOPSIS
doas [-aLsV] [-C config] [-u user] command [argument ...]
PARAMETERS
-a argument
Specify argument for the authentication function. Rarely used directly by users or for standard operations.
-C config
Check the syntax of the specified config file and exit. Useful for verifying configuration before applying it to /etc/doas.conf.
-L
List the commands the current user is allowed to execute according to /etc/doas.conf. This is similar to sudo -l.
-s
Execute a shell as the target user. If no user is specified with -u, it defaults to the root user's shell.
-u user
Execute the command as the specified user. If this option is omitted, the command is executed as the root user by default.
-V
Print the doas version information and exit.
command
The command to be executed with elevated privileges.
[argument ...]
Optional arguments passed directly to the command being executed.
DESCRIPTION
doas (dedicated openbsd application security) is a minimalist utility that allows a system administrator to delegate authority to specific users to execute commands as another user, typically the superuser (root). It was developed as a direct, simpler, and more security-focused alternative to sudo. The core philosophy behind doas is to provide essential privilege escalation capabilities with a significantly smaller codebase and fewer features, thereby reducing the potential attack surface.
Its configuration file, /etc/doas.conf, is designed for simplicity and clarity, using straightforward "permit" or "deny" rules to define who can run what, as whom, and under what conditions (e.g., with or without a password). When a user invokes doas, it checks the request against these rules, granting or denying access based on the first matching rule. This explicit configuration and "fail-safe" approach contribute to its robust security posture. doas has gained popularity beyond OpenBSD due to its simplicity and perceived security advantages.
CAVEATS
doas is intentionally minimal, which means it lacks some advanced features found in sudo, such as extensive logging capabilities, complex plugin architectures, or highly granular password timeout settings. Its configuration file, /etc/doas.conf, must be correctly configured; syntax errors or misconfigurations can lead to a complete denial of privilege escalation or unintended access. Because it adheres to a "first match" rule processing, the order of rules in the configuration file is crucial. Users migrating from sudo should be aware of these differences and carefully review doas's configuration requirements.
CONFIGURATION FILE (<I>/ETC/DOAS.CONF</I>)
The behavior of doas is entirely controlled by its configuration file, /etc/doas.conf. This file contains 'permit' or 'deny' rules. For instance, 'permit persist :wheel' allows users in the 'wheel' group to run commands as root after authenticating once per session. 'permit nopass :admin cmd /usr/bin/syspatch' allows users in the 'admin' group to run the syspatch command without a password. Each rule specifies the user, target user, command, and optional arguments. The first matching rule in the file that applies to the user and command request is used.
SECURITY-FIRST DESIGN
doas's primary design goal is security through simplicity. By having a significantly smaller codebase than alternatives like sudo, it inherently reduces the likelihood of complex bugs and vulnerabilities. The explicit nature of its configuration forces administrators to clearly define privilege delegation, enhancing auditability and reducing the chances of accidental privilege escalation due to implicit or overly broad rules. Its design prioritizes clarity and minimal attack surface.
HISTORY
doas was developed by Ted Unangst as part of the OpenBSD project. It was first introduced in OpenBSD 5.8, released in October 2015, with the explicit goal of providing a simpler, more secure, and auditable alternative to sudo within the OpenBSD operating system. The design philosophy emphasized minimalism to reduce the attack surface and simplify code review. Its success and adherence to Unix principles led to its porting and adoption by other Unix-like systems, including various Linux distributions, where it serves as a lightweight privilege escalation utility.
SEE ALSO
sudo(8), doas.conf(5)