|
|
|
|
|
by tetha
1318 days ago
|
|
Indeed, I've been looking around somewhat during off-time with a colleague how much we actually use of sudo, and what doas couldn't do. We're indeed looking at starting a migration, because some DNS based, LDAP integrated, PAM integrated, really complicated priviledge escalator is becoming kinda scary as of late. The biggest difference we found is that sudo is a little more convenient to manage with a config management solution, since each piece of config management code can just drop a file in /etc/sudoers.d. With doas, we have to coordinate a bunch of parts of the config management manipulating one file, /etc/doas.conf. This always turns out a bit messy. But maybe we'll just merge everything into one big and somewhat messy monster doas-conf-template with a ton of feature toggles and loops and go from there. But beyond that, almost all of our sudo rules are 2-3 patterns: Admin can sudo as everyone, zabbix/telegraf can run data gathering commands, and maybe some other automation triggers like pgbackrest wiping a postgres data dir during a restore, that's about it. All of those are pretty trivial doas rules all in all. |
|
Apparently whether it's used is configured at build time, because I get different results trying it on Arch and Alpine, but doas absolutely has a /etc/doas.d
EDIT: Oops, apparently Alpine added that - https://git.alpinelinux.org/aports/tree/main/doas/configurat...