Edit: Looks like their github readme outlines some of these limitations, https://github.com/memorysafety/sudo-rs#differences-from-ori...
The cool thing is running the editor via my user, which loads my user's configuration/plugins, instead of the root user's.
They indicate that many omittted features are by design, but this particular one is implied to be planned:
> Some functionality is not yet supported; in particular sudoedit
It’s a pity this isn’t more straight forward to implement on Linux.
However, I’m not sure that Linux is capable of masquerading as a general purpose capability based operating system. I think it’s missing a bunch of APIs.
This should be doable with an XDG portal model, right?
Maybe one could make a sudoedit that opens a file in sudo process and then spawns a non-privileged editor process which inherits the file descriptor and is given the /dev/fd/ path on the command line, so it stays none the wiser about the whole process.
I think the larger issue is that I doubt many (if any?) editors allow opening a file via an inherited file descriptor! I guess some will read stdin (the shim could close stdin and then dup2() it into its place), but then there's no way to save the file back when finished.
For a more complicated solution: spawn a zygote process early with a unix socket which you’ll use to send the fd later. Zygote at start drops provileges. When it receives the fd, it closes the socket and execs the editor.
There is the CLOEXEC flag which is the intended way to manage this but it’s not the default and you have to be diligent about setting it which again carries its own set of challenges.
What you’d really want is CLOEXEC implicitly on all fds and having to explicitly opt in for fd inheritance.
:w !sudo tee %
Which I map to :w!!
Of course, if you’re not using Vim, you’re doing it wrong :)
Now that I think of it, not sure how sudoedit behaves wrt this cached auth.
I have plenty of ideological problems with the design of the logs, but not actually ran into problems in the real world.
journalctl -f
Logs as a database is wildly superior to logs as a plain text file, with virtually the only downside being that you need a specific program to tail them.
The journal can output to text files as well!
But this is exactly it, my only issue is the ideological one that there is no spec for the database. The implementation is the specification, so the only true way of building a reader of logs is to implement the journal. There are attempts to document the layout but if there is any difference then you can't submit a bug to get the layout corrected but the implementation isn't wrong.
I can think of plenty of other applications with bigger issues than that. But I think can still want the defacto log for Linux to have an official spec.
As annoying as it is to have to update every sudo reference -> doas, it forces you to think about everywhere you're using it, rather than waiting to see what breaks and then trying to fix it.
In my scripts I never call sudo or doas. Instead, if the script needs to do something as root, I write the whole script so that it expects to itself be run as root.
And then when I want to run my script, I run it as root
doas ./somescript.zshIn my experience, and in my own scripts, it is better to explicitly check if you are being run as root, advise against it and exit (with maybe some break glass flags) and invoke sudo when escalated privileges are required.
You're taking a shortcut due to convenience and it's bad security practice.
It's that simple.
AFAIK sudo isn’t really tightly coupled to the kernel itself.
Except all exiting use of sudo ...
It's such an entrenched tool that I'm sure there a compatible replacement could be useful.
Personally I would appreciate someone to take on the mess that is PAM. It was much too complex from the start and it hasn't become better over the years.
That's a pretty general statement, and I'd say to that not really. It's very much a hobbyist OS. A few people use it at home as firewalls, a few small businesses maybe, but it's mostly hobbyists and developers.
> To say that it's a hobby project strikes me as very ignorant.
I mean, I've been familiar with the project for over 20 years, so I don't think I'm ignorant at all. The developers primarily make the OS for themselves and people with the same ideas and priorities.
> That said, it is not very easy to convince the developers that a function is missing because it's a pretty opinionated project, and they might not share the user's definition of needed functionality.
Right, the devs prioritize their own needs, and can do so because it's a hobbyist OS.
Sometimes reimplementing something and leaving out lesser-used features to "reduce the attack surface" can sound an awful lot like "let them pound sand".
I'm sure for someone out there that's a make-or-break feature, but for the vast majority trying to use OpenVPN it's a massive, insecure footgun. (Hell, how many bugs have protocol negotiation led to in OpenVPN/SSL/etc?)
Compare that to Wireguard that just says... it's encrypted. Full stop. Carry on.
A lot of this tooling and technology was developed in a different era with different priorities. Security, and especially network security, was not such a huge focus 30-40 years ago. Priorities have shifted. The operating environment is a lot more homogeneous (when's the last time you dealt with a layer 2 protocol besides ethernet?), while the risk of poor security has grown immensely.
It's absolutely fair to critically evaluate these features and determine which can be removed to simplify and improve the products for the vast majority of users. If a small fraction of users stay on sudo, but the majority are able to move to a more secure option... that's a win. This is exactly what Wireguard provides versus OpenVPN.
The binary executable will be bigger, but disk space is a lot cheaper nowadays, compared to 43 years back.
I mean, is there any time where one more level of indirection failed to make everyone happy?