brightsidedoas
sudo
su
other choice - please comment
Poll ended at .
Mark@brightside why should I move to doas?
JdeBP... except when you are using #ArchLinux, where the AUR #doas package has the #OpenBSD code, but the "official" doas package has had all of the OpenBSD code taken out and the timestamp files and other mechanisms from sudo substituted in.
https://github.com/Duncaen/OpenDoas/commit/74449f015ff7a72300be5a27680d2c70af309328
https://github.com/Duncaen/OpenDoas/commit/1899c37ea48dd1932edd913c510411ee4c9c242f
@JdeBP @brightside are you saying that on those platforms (that will include Ubuntu/Mint?) doas is just a "link" for sudo? A bit like MySQL is just a link for MariaDB (on those platforms)?
No. Someone took the portable #doas source code that targetted multiple operating systems, gutted all of the #OpenBSD parts from it, on the somewhat dubious grounds that the portable bits for other operating systems didn't build on Linux, and replaced them with mechanisms that work how sudo works. And they decided to name it "Opendoas".
And the people who put together #ArchLinux, #Debian, et al. decided that that was what they were going to officially ship as "doas".
judfilm
ben@judfilm @JdeBP @mark @brightside there is another port, which doesn’t (as far as I know) have these flaws. Presumably packaging that version instead would be a good start.
@benjamineskola @judfilm @mark @brightside
I pointed out the AUR having the other #doas package, earlier. So a good start for the #Debian and #Ubuntu and whatnots would be following #ArchLinux . Interestingly, Debian renamed its OpenDoas package away from the name "doas", although it still installs the command under that name, so the now unused package name is presumably reassignable. I think even the transition package is gone, now, although I haven't checked.
Bryan Steele 
@JdeBP @benjamineskola @judfilm @mark @brightside There is no official portable version of OpenBSD's doas(1), the 'OpenDoas' and 'slicer69' ports are both equally unofficial, and both include features/changes that are not a part of the OpenBSD native version, such as the PAM backend and in the case of OpenDoas "persist" feature emulation, which on OpenBSD was implemented with 3 new ioctl(2)'s:
https://man.openbsd.org/tty.4#TIOCSETVERAUTH
The "slicer69" port in particular has had security issues in the past, such a PAM authentication bypass, and also some dubious portability changes, such as replacing strlcpy calls with strncpy on Linux, etc.
https://github.com/slicer69/doas/commit/64ab988d34f95a7d9482152a74592ce32647d983
https://github.com/slicer69/doas/commit/720db7212167f05bcdcbb495147ef35b1e55d45c
https://nvd.nist.gov/vuln/detail/CVE-2019-15900
https://nvd.nist.gov/vuln/detail/CVE-2019-15901
I am not advocating for using sudo(1) over doas(1), certainly doas has a much smaller attack surface, but if you're running it on something other than OpenBSD, you're on your own.
@brynet @benjamineskola @judfilm @mark @brightside
The slicer69 #doas has, however, retained most of the tedu code, and added an #OpenBSD library compatibility layer to avoid changing some stuff. strlcpy() is in there, using millert's code.
Indeed, it has stuck to its guns over those very ioctl()s, pointing out that if one wants that functionality one needs OpenBSD for it.
As I've already pointed out, OpenDoas just wholesale deleted everything that conditionally compiled for non-Linux.
@brynet @benjamineskola @judfilm @mark @brightside
Ironically, one of its open bugs is completely down to #PAM, specifically #LinuxPAM not doing what #OpenPAM does.
https://github.com/slicer69/doas/issues/17#issuecomment-1553249174
The other open bug has a very simple and blunt answer: #doas cannot compile an ioctl() out of the Linux kernel. This is a bug against #Linux, the world knows it, and the bug filer should know it.
@JdeBP @benjamineskola @judfilm @brightside That's one of the issues I have with it, OpenBSD does not use PAM, it uses BSD Authentication.
PAM is not salvageable: https://www.dtucker.net/pam/
@brynet @benjamineskola @judfilm @brightside
Speaking as someone who put an event loop calling kevent() inside a #PAM conversation function just recently, I can say with authority that at least one of the tenets of that page is entirely wrong.
It's right about #LinuxPAM being buggy, and the fact that xyr bug got filed randomly against Fedora instead of against LinuxPAM itself is just one of the reasons that this sort of "upstream-downstream" development model is so frustrating.
@JdeBP @benjamineskola @judfilm @brightside It's good to hear the situation has improved regarding OpenBSD compat code, but the last time I looked the code was full of #ifdef __linux.
I haven't looked closely at what OpenDoas may have removed, there is no reason to be compiling either of these projects on OpenBSD, and none of the other *BSDs support BSD Auth or the previously mentioned tty authenticated session ioctl(2)'s.
@brynet @benjamineskola @judfilm @brightside
Of course it's going to have #ifdefs. It does PAM on systems with OpenPAM and LinuxPAM and BSD Auth on OpenBSD. It's a fairly superficial analysis to say that something is problematic because it has #ifdef __Linux__. Indeed, that's the same level of analysis as the OpenDoas author wholesale deleting all the code that's behind #ifdef __OpenBSD__, the exact commit for which is earlier in this very thread.
@JdeBP @benjamineskola @judfilm @brightside I'm not talking about PAM in this instance, I'm talking about other code that was carelessly replaced with poor quality reimplementation, and there are several notable examples of it that happened leading to exploitations on non-OpenBSD systems. There was a quality problem, which hopefully has improved.
@brynet @benjamineskola @judfilm @brightside
You in fact _are_ talking about PAM, though, because that's where 50% of the the #ifdef __Linux__ conditional compilation actually is, and 25% of it is in comments. (-:
Example: https://github.com/slicer69/doas/blob/master/doas.c#L423
