please
doas
Our great sponsors
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
please
- Please, sudo like program with regex support written in Rust
- Sudo: Heap-based overflow with small passwords
-
alias f*cking="sudo"
Someone already wrote a sudo clone in Rust and named it please: https://gitlab.com/edneville/please
- Be nice to your terminal.
-
I have no idea if this has been posted already
Or please, like sudo, but not. Especially if you want something like nice cookies, you should always say "please".
-
I did a thing.
please :)
-
Work fraud
Hey nice user name :) Looks like you're familiar with sudo, it is a bit self-promotional but I wrote an alternative to sudo that's now in some distros. It is over at please. Written in rust to avoid traditional c flaws. If you know regex, you'll probably like this.
-
I will be setting sudo to OwO
I just use please, https://gitlab.com/edneville/please No need for an alias.
-
A skin cream that obeys
Saw your flair, pleaseedit.
-
My new setup - Guys why isn't it working??
Self promotion warning, I've been working on a sudo clone called please. Written in rust to avoid traditional c flaws. I suggest trying it out to get more diversity in the ecosystem. Or not, totally up to you.
doas
-
Doas – dedicated OpenBSD application subexecutor
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
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)
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)
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
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]
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]
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
You can compile it from source : https://github.com/slicer69/doas
- trouble compiling doas
-
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.
What are some alternatives?
rdpwrap - RDP Wrapper Library
sudo - Utility to execute a command as another user
rudo - A toy sudo clone written in Rust
OpenDoas - A portable fork of the OpenBSD `doas` command
runas - An alternative to sudo and doas written in Rust
nosystemd.org - Website for arguments against systemd and further resources
SUDO_KILLER - A tool designed to exploit a privilege escalation vulnerability in the sudo program on Unix-like systems. It takes advantage of a specific misconfiguration or flaw in sudo to gain elevated privileges on the system, essentially allowing a regular user to execute commands as the root user.
sudo-rs - A memory safe implementation of sudo and su.
pac - Do you wanna Arch BTW but can't remember those pesky pacman commands ? Behold pac ! a simplified frontend to pacman.
svntogit-community - Automatic import of svn 'community' repo (read-only mirror)