sudo VS doas

Side note that I've always found interesting: sudo is almost entirely maintained by one dude: https://github.com/sudo-project/sudo/graphs/contributors

The n=2 case also occurs in the commit: https://github.com/sudo-project/sudo/commit/7873f8334c8d3103...

And indeed, the two values ate bitwise complements.

One feature they didn't mention they left out was the ability to run `make me a sandwich` (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)

It's (kind of) back - https://github.com/sudo-project/sudo/commit/9757d29a24ac1872872cf09757b0439c54089707

└───────────────────────────────────────────────────────────────────────────────────────┘

As a comparison, this is the output for https://github.com/sudo-project/sudo:

       0.0439 secs

Complete list (can be found here, files ins_*.h):

Fun fact, the “incident will be reported” message was close to being removed from sudo recently: https://github.com/sudo-project/sudo/commit/6aa320c96a37613663e8de4c275bd6c490466b01

OpenDOAS has actually had the OpenBSD-specific code removed, and replaces some of the doas mechanisms that rely upon OpenBSD to work with sudo-like flag files and suchlike.

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.

There's also a straight port of doas:

https://github.com/slicer69/doas/

However unlike sudo and opendoas this does not implement the persist feature on not-OpenBSD.

As mentioned elsewhere, this is because it relies upon a kernel mechanism that Linux simply does not have, and fixing this involves fixing Linux.

To which I add that it is important not to conflate Jesse Smith's doas, the portable doas that has code for different operating systems including OpenBSD, with Duncan Overbruck's OpenDoas, the "open" doas that is tied to Linux has has had the code for other operating systems removed and mechanisms copied in from sudo for things like timeout flag files.

* https://github.com/slicer69/doas

* https://github.com/Duncaen/OpenDoas

TIOCSTI is irrelevant. When one is dropping privileges, in a system cron job or in a process supervised by one's favourite service management system, there is no terminal involved. TIOCSTI simply doesn't enter into the picture at all.

Only when one is in a terminal login session and using su to elevate / add privileges, does TIOCSTI become relevant. But no-one here is saying not to use su to add privileges.

People blame su, sudo, and (as the person at https://github.com/slicer69/doas/issues/110 did) doas for this feature of operating system kernels. The right thing to do with TIOCSTI it to just eliminate it from the kernel. OpenBSD did back in version 6.

Sadly, the argument from Alan Cox, Linux developer, when this was proposed years ago was that it should stay in Linux, and all of the programs like su, sudo, and doas should have even more things to do in the parent process that sticks around, namely pump I/O to and from a controlling pseudo-terminal that su/sudo/doas sets up for the shell subprocess, breaking (as the maintainer of OpenDoas pointed out) the long-standing notion that the child processes belong to the same terminal session and share things like a single getlogname() with the login shell.

6 years after https://www.openwall.com/lists/kernel-hardening/2017/05/10/3... and https://www.openwall.com/lists/oss-security/2017/06/03/9, there is no sign of anyone doing anything of the sort in any su or doas implementation. (It was briefly in one su implementation, but taken out in 2017 for being a "stupid hack": https://github.com/util-linux/util-linux/commit/23f75093264a...)

Fortunately, some six months ago Linux developers finally made TIOCSTI removable and the right course of action is available to those that want it: https://lore.kernel.org/lkml/20221228205726.rfevry7ud6gmttg5...

It's more likely that this is the entire "upstream downstream" development model in action again.

There are vast numbers of improvements to softwares that never get sent to the places where they will do the most good (or at least have a proper record of why they were rejected by their authors). A quick perusal of the bug trackers of Debian or Ubuntu will reveal tonnes of local patches that the original authors of the softwares often never even hear about.

Things don't "stick" often times simply because they get lost.

I was looking at something like that just the other day. Here's a bug report that describes a problem with "doas" not opening the controlling terminal to do its authentication dialogue. This is actually a problem with a package named LinuxPAM, and doesn't occur when "doas" uses OpenPAM or BSD Auth. It's LinuxPAM that's where the code in question is. Fixing LinuxPAM would improve the lives of everyone that uses LinuxPAM, because the behaviour of not allowing standard input through in a command pipeline is not confined to "doas" but affects everything that uses LinuxPAM to do login authentication.

But time and again stuff like this languishes in the wrong place, for years and decades.

* https://github.com/slicer69/doas/issues/17

Now that you have your headless Debian server running, and you’ve installed doas and Webmin, we’ll get things rolling by installing:

Now, let’s replace “sudo” with “doas”. Type git clone https://github.com/slicer69/doas.git to download doas from Github.

You can compile it from source : https://github.com/slicer69/doas

It's also the one with a history of critical security issues because the maintainer has no idea what he's doing porting OpenBSD code to Linux.