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,
make install, will call the program
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:
Module name: src
Changes by: [email protected] 2015/08/28 07:19:50
usr.bin/doas : doas.conf.5
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").
Why is this useful?
Imagine a script that does some things that need root privileges;
something like this:
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
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
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