Translation(s): English - Català - Español

Doas is a utility that allows a user account to run a command as another user account. You can think of it as, do it as someone else (hence "doas"); although it was not intended and the name was actually an accident.

Doas is intended as a minimalist replacement for the more popular sudo, providing "95% of the features of sudo with a fraction of the codebase", potentially improving security. It is a port of the OpenBSD command by the same name. It also has a much simpler configuration format, simplifying setup.


Doas is available in Debian. Install the doas package.



Doas is useless out-of-the-box. Attempting to use it in any scenario will error out with:

doas: doas is not enabled, /etc/doas.conf: No such file or directory

As it prompts, you can create and edit /etc/doas.conf as root, and start adding rules for it. Each rule occupies a new line. The priority list for conflicting rules is bottom-to-top. The last matching rule determines the action taken.

A very simple line in /etc/doas.conf would look like:

permit johnsmith as root

In short, this would enable the user, johnsmith, to run commands as root after entering his own password. Hence, johnsmith is indirectly given root privileges.

More broadly, this command can be broken down into three components. permit is the action. This can instead be deny to explicitly deny permissions to someone. Hence "deny johnsmith as root" would mean that, if that rule is on the bottom of the list, johnsmith can never act as root, regardless of any other rules which may imply otherwise. This is useful for, e.g., permitting all members of a group except one.

johnsmith is the identity. This can be a username, group (when prefixed with a colon), or numeric user ID.

as root is the target. In this context, you can similarly replace "root" with any username, group, or numeric user ID. This field is also optional, with the default being all users. If the full line was simply "permit johnsmith" then that user could run any command as any other user.

Comments are signified with hashmarks (#). See doas.conf for detailed rules. Also, there is an example of a simple configuration file in /usr/share/doc/opendoas/examples/doas.conf, which you can use as a starting point to create your own doas.conf file.

It is advisable to check doas.conf for syntax errors every time you modify it; see usage.


There are a number of optional arguments that can provide additional flexibility. The full command format for doas is:

permit|deny [options] identity [as target] [cmd command [args ...]]

For full details, see doas.conf, but we'll briefly cover some of the main ones here as well.


One of the available options is nopass, which disables the prompt for a user's password when using doas. For instance:

permit nopass johnsmith as root

This will allow the user to run any command as root instantly, with no need for johnsmith to provide his own password. There is an intermediate choice between permit and permit nopass: the persist option. With this option the user will be prompted to enter the password only the first time, afterwards will not be asked for it again for some time.

Two other available options are keepenv and setenv. keepenv ensures that environment variables are retained when creating the environment for the new process. setenv is for preserving or setting variables that will be passed to the command. Your list of variables is wrapped in curly brackets, with each one space-separated. Use an equals (=) sign to set a variable, or just list the variable name alone to preserve it. Prefix your variable with a minus (-) sign to unset it. Use a dollar sign ($) to refer to an environment variable.

Restricting commands and arguments

The "cmd" section, as noted in the format, allows restricting the rule to only allow execution of a certain command, potentially only with certain arguments or subcommands. See:

permit johnsmith as root cmd apt args update

The main command is prefixed with "cmd" and any arguments or subcommands are prefixed with "args". If the line ends with "args" and nothing else, it will disallow all arguments. As-is, this example would allow user johnsmith to only run apt update as root. Any additional subcommand, any additional arguments, or any lack of either, would error out with "Operation not permitted".


This example line demonstrates a number of these advanced options at once:

permit nopass setenv { -http_proxy APT_CONFIG=/etc/apt/apt.conf.d/50appstream } :updaters cmd apt args update

This permits any member of the group "updaters" to execute "apt update" without needing a password, while unsetting the http-proxy variable and setting the APT_CONFIG variable to the path of one of Apt's configuration files.


A basic PAM configuration file is shipped with the package, at /etc/pam.d/doas.


Outside of what's documented in the configuration section, there's also some standard functionality built into the doas command.

By default, all usage of doas will assume your target is root. The -u flag allows you to explicitly specify a different user to run a command as. for instance:

> doas -u juliasmith whoami

If the "juliasmith" user exists, and if your account has permission to act as her, this would print her username, i.e. "juliasmith"

The -s flag can be used to launch a shell as a user. For instance:

> doas -s

This would open a root shell, as root is the default target. Or:

> doas -u juliasmith -s

This would open a shell as juliasmith by specifying her as the target.

The -n flag enables non-interactive mode. If a password would be required (i.e. if the "nopass" option isn't set for the matching rule), the command fails.

The option -C allows to check a configuration file for syntactic errors. For instance, after you are done tuning your /etc/doas.conf, run

> doas -C /etc/doas.conf

which will output something only in case there are any syntax errors, and nothing if the file is well-formed.

Additionally, the -C option is useful to do logical checks: which specific rule will be applied to a given command and arguments, without actually running the command. Assume an /etc/doas.conf made up of these two rules

# Allow members of group updaters the use of apt as root, but only with argument "update"
permit nopass :updaters as root cmd apt args update
# Allow johnsmith to run "apt upgrade" as root.
permit persist johnsmith as root cmd apt args upgrade

then, assuming the user johnsmith is in the updaters group and executes the following commands

> doas -C /etc/doas.conf apt update
permit nopass
> doas -C /etc/doas.conf apt upgrade

Because the first command issued matches only the first rule; while the second command matches both, hence the last match (second rule) is applied. For any other user in updaters group, the result would have been permit nopass and deny, respectively.

See also

External links

CategoryRoot | CategorySystemSecurity | CategorySystemAdministration