On 2026-08-03 03:46 PM, David C Rankin wrote:
On 8/3/26 8:02 AM, Ralf Mardorf wrote:
I know that a subscriber went to the trouble of setting up "doas", but
if I recall correctly, in some cases it doesn't work well with Arch
Linux.
I find it unacceptable to do away with sudo or a replacement entirely
and rely solely on su, for various reasons.
This was recently discussed on opensuse-factory as well, with the same
sentiment. sudo is practically ingrained in 30 years of Linux backend scripts
and system administration workloads. There would be significant breakage and
disruption by its removal.
While the idea may be to protect users, the disruption to system administration would be
severe. The policy of "go fast and break things" isn't a sane policy regarding
sudo.
Well, sure there are some things that do not work as-is with opendoas, and what's worse
is that there are some admin scripts or even binaries calling sudo underneath, but I'd
argue that most of what I regularly do is OK with opendoas with a cleaner and smaller
code base which I guess also makes it easier to audit. And for some non supported
things, there's "su" from util-linux so you don't need execute things as root,
but rather execute them being root. It doesn't have to be all or nothing, does it?
But perhaps to the original idea of building packages as non root, I think the clean chroot
procedure could be tweaked to do everything, including downloading and building, as regular user.
Chroot provides a root shell in the end, but a non root regular user can be created with it
including a home directory for it, and then chroot can be scripted so that it does some things as
the created non root user. This would require changes on the clean chroot procedure to automate
the creation of the non root user, but nothing impossible, see [1]. And for those not using the
clean chroot for whatever reason, the typical path should be to build as non user with makepkg, and
only when installing the package use "doas" or whatever allows to execute as
"root".
I guess when someone says opendoas is not good enough because not 100% compatible with sudo, if they make a
list of what really can't be done with opendoas they'll find out those are just a few things, and perhaps
there's a simple way to get away with those without requiring sudo in the system. This might alter the
current use of sudo, but not dramatically for the more common flows, and yes, as there are sudo configs, one
needs to do some opendoas configs which for sure the ones from one are not a copy/paste from the other, but
those can be understood from the "doas" and "doas.conf" man pages. Clearly a 100%
compatibility and no effort ever when attempting to replace sudo with doas on every single flow admins use is
not going to work, but I'd bet you could get away with 90% or more of those flows (just a bet, and just my
two cents), and with that you could ditch a source of several privilege escalation issues being found on
sudo, with I "bet" not that much effort.
A very particular case is binary closed source software, many making assumptions about
sudo being available on the system and executing it from within the software itself, and
if there's no access to the internet involved and/or building process involved, one might
get away with login as root or use "su" to execute that software. But such
software unless mandatory by your employer or similar should be avoided in the 1st place
given there's no way to audit it.
Greetings !
--
Javier
[1]
https://linuxvox.com/blog/bash-executing-commands-from-within-a-chroot-and-switch-user
