Doas Alternatives

doas reviews and mentions

• Doas – dedicated OpenBSD application subexecutor
  2 projects | news.ycombinator.com | 29 Aug 2023

  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.

• Testing the memory safe Rust implementation of Sudo/Su
  9 projects | news.ycombinator.com | 28 Jun 2023

  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.

• Doas Mastery (2019)
  3 projects | news.ycombinator.com | 16 Jun 2023

  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

• Don't abuse su for dropping user privileges (2015)
  3 projects | news.ycombinator.com | 26 May 2023

  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...

• Linux tool to show progress for cp, mv, dd
  7 projects | news.ycombinator.com | 19 May 2023

  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

• Installing Docker and a media stack (Plex, *arrs, download clients, elaborate script) [Text]
  13 projects | /r/tutorials | 6 Sep 2022

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

• Installing a headless Debian (Linux) server for file storage and other cool stuff [Text]
  3 projects | /r/tutorials | 5 Sep 2022

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

• Trying to install doas and other programs
  1 project | /r/redhat | 24 Aug 2022

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

• trouble compiling doas
  1 project | /r/illumos | 16 Jun 2022
• DOAS
  3 projects | /r/archlinux | 30 Oct 2021

  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.

• A note from our sponsor - SaaSHub
  www.saashub.com | 27 Apr 2024

  SaaSHub helps you find the best software and product alternatives Learn more →