systemd Rolling Out "run0" As sudo Alternative

[andyprough]

Just what I wanted this morning - Microsoft re-writing my sudo for me.

[Artim]

Just what I wanted this morning - Microsoft re-writing my sudo for me.

What a clown🤡

sudo has been having many issues over the years, especially ones that can be abused as security issues.

[cjcox]

Nobody can take utilities with thousands of valid use cases and narrow it down to the only 3 use cases the world needs.

[skeevy420]

Sure, lets do things the worst way possible, the Windows way that's being abused by malware/ad ware and is just undecipherable by 99+ % of all users. Sure, dconf is leaps and bounds better - not that hard to do things better than MS - but that's also owed to the fact that only Gnome apps integrate with it, not every single goddamn app there is. Thanks, but especially the way of just putting system-wide configs to /etc - and distros like Debian enforcing that practice - is hands down the most sane option there is. So yes, Linux has afreed on a sensible way to configure things, and the best thing about is that it's not the MS way of doing things.

That's because security was an afterthought with Windows. Windows, until 8, was operating on the premise that users would connect and disconnect from the internet manually, that the internet wasn't an always-on service, so all users were basically treated as root users. Even on 8+ gaining root isn't much harder than clicking yes when prompted. I'll trust SELinux, AppArmor, user/group, 644/755, etc over WTF Windows has going on where we're not even password prompted by default.

Anyways, I'm not saying that databases are the end-all solution, just that every program doing everything in its own manner exponentially increases the difficulty of using and maintaining a system and that agreeing on some forms of unified settings solutions would make it easier for people to use and for tools to audit. Like Windows, both methods are prime targets for hackers. Obscurity via one thousand methods is just as bad as visibility via one method.

[RealNC]

Even though I've used Linux for so long, to this day I still don't know what the proper way is to run a program (be it GUI or command-line programs) with root permissions but with the current user's UID. So configuration for example is looked up in /home/me/.config, not /root/.config. And saved files still belong to me, not root. Basically the equivalent of the "Run as Administrator" function in Windows. Is that even possible on Linux without needing the program itself to explicitly implement that (by asking for the root password when you start the program.)

I assume "run0" doesn't solve that issue.

[Artim]

That's because security was an afterthought with Windows. Windows, until 8, was operating on the premise that users would connect and disconnect from the internet manually, that the internet wasn't an always-on service, so all users were basically treated as root users. Even on 8+ gaining root isn't much harder than clicking yes when prompted. I'll trust SELinux, AppArmor, user/group, 644/755, etc over WTF Windows has going on where we're not even password prompted by default.

Anyways, I'm not saying that databases are the end-all solution, just that every program doing everything in its own manner exponentially increases the difficulty of using and maintaining a system and that agreeing on some forms of unified settings solutions would make it easier for people to use and for tools to audit. Like Windows, both methods are prime targets for hackers. Obscurity via one thousand methods is just as bad as visibility via one method.

There's just no need. A well written program has a well documented and commented config file, so it's absolutely irrelevant how a dev dies things, as you are delivered and information you need with the config file. And the different formats are for the different programming languages used to write the programs in and thus to parse the files with. Sure, you could somehow cook up something that can be used by any language, but then you are just creating a problem to find a solution nobody will bother to use anyways. Just leave things the way they are. They work and they work great. And they are very easy to make a backup of, to edit even when you have to mount the system into a live system, and you can easily transfer them to any other device since you'll always only transfer what you need without the danger of just dumping a whole database and cause issues upon import. There's a reason why things work the way they do.

[Artim]

Even though I've used Linux for so long, to this day I still don't know what the proper way is to run a program (be it GUI or command-line programs) with root permissions but with the current user's UID. So configuration for example is looked up in /home/me/.config, not /root/.config. And saved files still belong to me, not root. Basically the equivalent of the "Run as Administrator" function in Windows. Is that even possible on Linux without needing the program itself to explicitly implement that (by asking for the root password when you start the program.)

I assume "run0" doesn't solve that issue.

Then you haven't tried to find out. Any decently written program uses relative paths for these things and not absolute ones. So as long as you don't use something that not only switches users but also the environment variables, that's exactly what will happen. So taking a glance at the man pages of sudo would have told you that the flag -E will tell it to preserve the environment variables. And even googling it would have told you within 30 sec.

Also, the article implicitly says that there will be a whitelisting mechanism. So if run0 is supposed to support that feature, you'll be able to do so.

[RealNC]

Then you haven't tried to find out. Any decently written program uses relative paths for these things and not absolute ones. So as long as you don't use something that not only switches users but also the environment variables, that's exactly what will happen. So taking a glance at the man pages of sudo would have told you that the flag -E will tell it to preserve the environment variables. And even googling it would have told you within 30 sec.

I already know about that. But it's still not the proper way, because files I create in the programs are owned by root, not me. Configuration files too (depending on how the program updates its config files.) The process still runs with UID 0. It should run with my own UID, but have root permissions.

[varikonniemi]

You're highlighting a bigger problem with computing in general -- a combination of how there aren't always standards and protocols, like POSIX and Wayland, for developers to follow and that when they exist to be followed, they aren't always followed or done in a compliant manner. That's why we have a clusterfuck under ~/.config, ~/.local, $HOME, and other places just for configuration files. God forbid "Linux" could agree on a database/registry way to configure things like Regedit or Gconf instead of the shotgun blast of plaintext, databases, XML, JSON, etc we currently have.

Systemd is the same and both user1's post questioning the quality of resolved and Kjell's post about Arch/Artix dependencies really highlight it. A lot of things get added to systemd but it's like there is no framework around how systemd does things and how to systematically replace what you do and don't like about systemd from some other project. Not saying that stubs and compatibility layers aren't in use, but people speak of swapping systemd and systemd modules like it's as easy as switching windows managers on an X11 system when it's more like switching window managers on a Wayland system (standards and protocols only do so much when interoperability isn't part of them or there isn't a common base to work with like with X11 & Wayland).

You go to remove a package and 14 systemd packages come up for removal. You go to install a package and you're not asked if you'd like to use systemd-cryptsetup or openrc-cryptsetup like how KDE asks about gstreamer and vlc backends or how you get to pick between mpv or mplayer for some things. It's not like we can run update-alternatives on systemd and openrc modules. Unless you're a hardcore geek, you're basically stuck with whatever init system your distribution ships.

I'm mostly saying systemd up there, but it's really an init system issue. You can't blame systemd too much when there isn't a standard to follow or standard governing body to join to better cooperate with others.

The minimum systemd should have done is that all the things it touches/replaces could be swapped in simply by installing it and masking systemd's replacement. This would be following the standard. The standard being how things currently work in practice.

[andyprough]

sudo has been having many issues over the years, especially ones that can be abused as security issues.

Which is why we have doas. You should read a bit more before you go on your posting rampages, you would look less foolish if you educated yourself even the slightest little bit.