Why would root need to run unrestricted commands as itself via doas?

Question

I've just come across doas, and while reading the man page for its configuration I found this example:

The following example permits users in group wsrc to build ports; wheel to execute commands as any user while keeping the environment variables PS1 and SSH_AUTH_SOCK and unsetting ENV; permits tedu to run procmap as root without a password; and additionally permits root to run unrestricted commands as itself.

# Non-exhaustive list of variables needed to 
# build release(8) and ports(7) 
permit nopass setenv { \ 
        FTPMODE PKG_CACHE PKG_PATH SM_PATH SSH_AUTH_SOCK \ 
        DESTDIR DISTDIR FETCH_CMD FLAVOR GROUP MAKE MAKECONF \ 
        MULTI_PACKAGES NOMAN OKAY_FILES OWNER PKG_DBDIR \ 
        PKG_DESTDIR PKG_TMPDIR PORTSDIR RELEASEDIR SHARED_ONLY \ 
        SUBPACKAGE WRKOBJDIR SUDO_PORT_V1 } :wsrc 
permit setenv { -ENV PS1=$DOAS_PS1 SSH_AUTH_SOCK } :wheel 
permit nopass tedu as root cmd /usr/sbin/procmap 
permit nopass keepenv root as root 

root is root, why would it need permissions?

Note: I've tagged this with sudo as doas is a substitute/successor, so perhaps the reasoning or concepts will come from sudo or apply to both.

Answer 1

You take that comment out of context. This line is useful when building ports:

permit nopass keepenv root as root

Building ports always calls doas. Without the line above, this would restrict environment variables even when building ports as root. With said line building ports as root is done with the full environment.

Answer 2

I disagree with part of the other answer: building ports by itself does emphatically not always call sudo (or doas) and should be done by a regular (dedicated) user.  Only some of the make targets, e.g., those that install or uninstall ports, like make install, will call the program SUDO, if it was specified in /etc/mk.conf or the environment.  The reason for mentioning this setting in the manual is for bulk builds with dpb(1).

---

The reason the line is there is backwards compatibility with OpenBSD's default sudoers file, as the commit message mentions:

CVSROOT:        /cvs
Module name:    src
Changes by:     [email protected]     2015/08/28 07:19:50

Modified files:
        usr.bin/doas   : doas.conf.5 

Log message:
Document an example that lets root run unrestricted doas commands as
root ("permit nopass keepenv root as root"), matching the old
behaviour from OpenBSD's sudoers file ("root ALL=(ALL) SETENV: ALL").

OK sthen@

Why is this useful?  Imagine a script that does some things that need root privileges; something like this:

#!/bin/sh
cmd1
doas cmd2
cmd3

You can run this script successfully only as a user that has permission to use doas.  By default, no user – not even root – has the right to use doas; you have to opt in explicitly by adding rules to /etc/doas.conf.  Without the line permit root as root, the above script would fail if you run it as root, which is probably surprising and inconvenient.

Now comes the part where I agree with the other answer: as mentioned above, the default build scripts in OpenBSD have the variable SUDO that you can set to sudo or doas to elevate privileges.  If any command is run under $SUDO, you want to preserve environment variables, such as directory prefixes and other things needed by the build system to work properly.

---

One more thing: note that only the big first example in the quoted manual excerpt is intended for building ports.  Read the quoted text as a bulleted list with four independent items:

The following example

• permits users in group wsrc to build ports;
• [permits] wheel to execute commands as any user while keeping the environment variables PS1 and SSH_AUTH_SOCK and unsetting ENV;
• permits tedu to run procmap as root without a password;
• and additionally permits root to run unrestricted commands as itself.

Obviously, the example involving procmap has nothing to do with building ports, and the second example is just the customary thing that members of group wheel are those allowed to elevate privileges to root (e.g., via su, sudo, or doas).

Now why would you want this?  Well, some scripts or makefiles contain a SUDO variable.  By default, no user has the right to use doas.  You have to opt in explicitly by adding rules to /etc/doas.conf.