Learn OpenBSD - User, Group & doas

#Introduction

In episode 4 you learned how to extend the system with packages. But a system without managed users is an open door. This episode is about who may enter the system and how they get privileges — two core security questions.

On OpenBSD the answer is concise: users are managed with useradd/adduser, groups with groupadd, and privilege escalation is handled by doas — a sudo replacement designed from scratch to be as simple and secure as possible. No sudo, no long configuration files; that's exactly its strength.

#Users on OpenBSD

#/etc/passwd and Identity Files

User information on OpenBSD is stored classically: /etc/passwd contains the list of accounts, /etc/master.passwd (root only) contains the version with hashed passwords, and /etc/group maps group membership. Changes are made through dedicated commands, not manual file edits.

#Creating Users with useradd

The main command is useradd:

Creating a user

useradd -m -s /bin/ksh arman
passwd arman

-m creates the home directory at /home/arman.
-s specifies the login shell (the OpenBSD default is /bin/ksh).
After creating the user, set a password with passwd.

Other variants:

adduser: interactive, good for beginners, guides you step by step.
userdel: removes a user; userdel -r arman also removes the home directory.
usermod: changes user properties, for example usermod -s /bin/zsh arman.

#Groups and Membership

Groups are created with groupadd and membership is managed via usermod:

Creating a group and adding a user

groupadd www
usermod -G www arman
id arman

id arman displays the UID, GID, and the groups the user belongs to. Groups matter on OpenBSD because many privileges (device access, certain permissions) are granted through group membership. For example, a user needs to be in the operator group or a specific group to access certain devices.

Warning

Some groups on OpenBSD grant real privileges, for example wheel (can use su to become root) and staff (can access more memory resources). Grant group membership sparingly, according to the least privilege principle.

#doas: The sudo Replacement

#Why doas

sudo is a large utility with many features, complexity, and a history of security bugs. OpenBSD wanted something small, clear, and audited: that's doas. doas's code is very compact, its configuration is easy to read, and all its behavior is easy to predict. There are no unused features carrying hidden risk.

#The /etc/doas.conf Configuration

All of doas's policy lives in one small file, /etc/doas.conf:

Example /etc/doas.conf

permit persist keepenv :wheel
deny nopass
 
permit nopass :backupcmd

The first line allows all members of the wheel group to run commands as root, with persist (no password prompt for a few minutes after a successful authentication) and keepenv (keeps the environment). The second and third lines show the deny/allow pattern: rules are evaluated top to bottom, and the first matching rule wins.

#Everyday Usage

Running commands with doas

doas pkg_add nginx
doas vi /etc/pf.conf
doas -u www /usr/local/bin/script

doas without arguments runs a command as root. The -u user option runs a command as another user. Since doas is not sudo, never try sudo — it doesn't exist on OpenBSD.

#doas config

To check the syntax and validity of the configuration:

Validating the doas configuration

doas -C /etc/doas.conf
doas -n doas-config

doas -C validates the configuration file without executing a command — the same habit as pfctl -nf in episode 12.

#doas vs su

Aspect	doas	su
Privileges granted	Per ruleset, can be per-command	Always full root
Authentication	Password of the user running it	Root password
Auditing	Logs via syslog	Depends on shell configuration
Granularity	Can restrict commands & users	All or nothing

For day-to-day administration, doas is preferred: granular, logged, and without sharing the root password. su still exists, but is considered an emergency path.

#Least Privilege in Practice

Imagine a web server: you wouldn't log in as root to manage content. Create a regular user for deploys, give them the right group membership, and only give root access for tasks that genuinely need it. Whenever you feel "ah, just use doas once", remember: doas is available, but the appropriateness of running a root command must be questioned first.

#Closing

In episode 5 you managed OpenBSD identities comprehensively: creating users with useradd and adduser, configuring groups with groupadd, understanding /etc/passwd and /etc/group, and replacing sudo with the simple and secure doas via /etc/doas.conf.

Key takeaways:

Users are created with useradd -m -s /bin/ksh, and groups with groupadd.
wheel and staff are sensitive groups; grant membership sparingly.
doas is the sudo replacement: small configuration, rules evaluated top to bottom.
doas -C validates the configuration without executing.

In the next episode, episode 6, we'll manage base system services and the rc system — understanding /etc/rc.conf, enabling services with rcctl, learning about the scripts in /etc/rc.d, and how to set a service's flags. Your system is coming to life with managed services!