I have no problem with doas on debian or arch through a package either.
Many sudo policies are often kind of horrible (even by default) and often facilitate privilege escalation, and then there was CVE-2019-14287 ( < 1.8.28 ) and CVE-2021-3156 ( < 1.9.5p2 ) which were plenty nasty. It's just way too huge for a setuid program, security tools shouldn't represent security holes as best as we can get away with it.
Opendoas isn't immune to security problems, either, [1] but I try to have a policy of trying to use smaller programs and libraries of higher quality and sudo just isn't fitting the bill here. In production systems neither really needs to be installed/enabled (especially just to faciliate a local user to do whatever root can do), and su does just fine for administration tasks as long as you don't do something stupid like leave it logged in on tmux.
There are, moreover, 2 ports of doas to other systems. OpenDOAS is one. Jesse Smith's https://github.com/slicer69/doas is the other. The latter retains the OpenBSD-specific code, and is the more portable of the two at the expense of only doing everything that the tool is capable of when actually built on OpenBSD.
Be aware, the project has turned off soft updates while they take a turn through filesystem land unlocking it. I have to admit given their reasoning I am not sure if it will come back. I always thought it was cool but I don't think it ever did all that much for performance or reliability.
Some context for them unfamiliar with soft-updates. it is an interesting system where writes are delayed and rearranged so they tend happen in-order, it was supposed to improve speed a bit(more writes in order) and resiliency(fewer states where the file system will corrupt on power outage) but it may have been too clever for it's own good. Nobody in the openbsd project wants to deal with it's complexity while they removes locks from the vfs layer.
Current has a habit of turning into release. And I am probably reading way too much into this, I have so special insight in the inner workings of the openbsd project. But if the people digging around in the filesystem code don't want it around while they work, I have no real hope for it to go back in when they are done.
is this actually going to wind up stopping Sudo bash or is this "if you use it right you don't need to" which is a euphemism for "yea but everyone does"
Anecdotal, but I've been using the doas in Arch's repository since switching to it. So far, I haven't come across anything that requires sudo instead of doas.
Doubt it. The one thing doas is missing (from my POV) is caching the authorization. Sudo will allow you to cache the authorization on every(?) platform, but doas will only allow this on OpenBSD. If you're running "sudo bash" to avoid reentering your password a million times, doas (likely) won't help.
However if you're running "sudo bash", you should probably consider setting the root shell appropriately and just use "sudo -l".
No problem. FWIW I use doas over sudo on all 3 of my Nix hosts and I've only ever had one issue - VeraCrypt has a hardcoded shell-out to sudo, so I can't use it.
The proper fix would be VeraCrypt implementing polkit, but I just use cryptsetup's implementation.
This is actually an interesting case. Openbsd implemented timing out the connection by adding it to the tty[1]. this sort of shenanigan would never fly on linux, "what! improve an unrelated established system, I don't think so." So for a long time doas on linux was not able to timeout a session. At some later point the timeout code was re-implemented on linux using a different mechanism[2].
If your linux doas does not timeout, try updating it?
Keeping the environment via `sudo -E` is slightly trickier.
If you need that for a fixed set of commands you can enable keeping the environment for those explicitly via the configuration file using the `keepenv` option. You can also set specific variables for specific commands,
But you would need to use a workaround if you want to keep the environment for a command without always adding that to the configuration, one way would to add a wrapper executable and add a permanent rule for that, e.g. something like the following should work:
# reuse the `env` tool, but use an explicit symlink to have clear boundaries
ln -s /bin/env /bin/keep-env
# add rule for keep-env to doas cfg, replace USER with your user name, or prefix with : for a group
echo 'permit persist keepenv USER cmd /bin/keep-env' | tee -a /etc/doas.conf
# run command
doas keep-env THE-ACTUAL-COMMAND
Disclaimer, not deeply tested and there might be even better options, but FWIW, this workaround is at least quite simple in principle.
It was probably some sort of database error page, (wild ass guess). the site got hugged, the backend took a little to long and a snarky error message popped out.
https://cr.yp.to/daemontools/setuidgid.html
https://cr.yp.to/daemontools/envuidgid.html