Should you edit the /etc/sudoers file or should you add a user to the sudo group? I cannot intuitively figure out what the differences are and I am curious what other prefer? Is it a method of implementing redundancy to have two different methods to allow users to execute commands requiring root privileges?
It’s not redundant: the /etc/sudoers file is the “source of truth” where you need to add your users and groups that will be able to invoke the sudo command. By default, a group aptly called sudo already exists, which you can use as a shorthand by adding and removing users to it. This is simply more convenient: it’s faster, easier to automate, less prone to errors, etc.
I prefer using opendoas and defining the user itself in /etc/doas.conf (or /etc/doas/doas.conf on other distros). Because I’m mostly a single user, I don’t need to specify the sudoer group, so I just add a user.
If you have many users to manage and you don’t want a whole group, or you need particular users to user particular commands, you can define each of them in /etc/sudoers.d, one per file and their allowed sudo commands. The later is generally the preferred method, but I see most companies just opt for a wheel or sudo group and nobody adds users to /etc/sudoers.
It’s mostly a matter of management approach.
1 Like
I didn’t know about opendoas, does it have anything special that sudo doesn’t? According to Arch wiki it seems like a smaller version of sudo which I guess makes sense for smaller setups but I’m not sure which features I’m not even aware from sudo that I don’t need.
It has the minimal set, like allowing users to execute all commands as root, only certain commands as root, deny certain commands, don’t require password for certain commands and has timeout (to not always ask for password on each command, if they are done between short intervals).
Sudo has a lot of cruft that is useful for enterprise admins, like a session recorder that sends it to a central server, it has an audit that sends sudo commands over to /var/log/messages (I think in json format), approval API (to meet certain additional criteria for running certain commands, without changing the sudoer file itself) and more. I’ve never seen home users make use of any of the advanced sudo stuff (in fact, all sudo home usage I’ve seen are either allow all for user or group, with sometimes allow command without requiring password).
Sudo also has more attack surface, which is why doas is preferable if you’re not even making use of most of sudo’s features. This is probably why OpenBSD developed doas in the 1st place (opendoas is a linux port of doas that tries to allow all doas features on linux and nothing more - for example, the original doas will not have working timeout / persist feature working on linux, because it uses specific openbsd features, while opendoas fixes that).
1 Like
Thanks, I’ve installed it and aliased sudo to run opendoas. I’ll check it out for a while and see if I even remember it’s there 
1 Like