return to table of content

Run0, a systemd based alternative to sudo, announced

kbar13
121 replies
1d10h

systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run globally to the front of the filename". it's provided an extensible platform with which higher level orchestration frameworks like ansible / ignition can easily templatize services or other system configuration.

since the beginning of systemd people have moaned about how complex it is and how we're reinventing the wheel. yet time and time again the people actually working on the project show that the solution they've come up with is the result of the problem they're facing on a daily basis. it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back", maybe think about whether or not you have a legitimate issue not being addressed by the solution proposed or if you are just getting rage baited by a headline.

agilob
69 replies
23h20m

remember when you had to write bash scripts to start, stop, restart services

This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename.

The init system was probably peak of systemd, after that they started reinveting things in a more complicated way. Do we really need journald, systemd-boot, machinectl, systemd-networkd, sd-bus, systemd-resolved, systemd-nspawn? Do people actually use it all? Are there any metrics to show how many systems have it installed and in use?

lolinder
34 replies
23h2m

I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`.

journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there.

I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename.

My memory of this time was that every single application had its own unique method of handling logs and its own unique location for storing them. So sure, once you found the logs you didn't have to Google how to find the relevant dates if the application is using logrotate as you describe, but finding the logs in the first place was always a challenge. Systemd is nice in that it provides a single place where all logs go and a single interface for navigating them.

cogman10
13 replies
22h13m

I think my biggest gripe with journalctl is (and this may just be because I'm novice at using it) that discovering what sort of logs are on the system feels a lot more complex.

With regular logs, I can go to /var/log, ls the dir, and get a nice list of what's being logged. There will be, for example, an `apache.log` file that has all the logs relevant to apache.

tapoxi
12 replies
22h0m

It's just journalctl -u apache -f, assuming your distribution calls the unit file "apache", and the last few messages of the logfile appear with systemctl status apache

And you don't need to worry about "is this service rotating logs appropriately?"

cogman10
11 replies
21h56m

The important thing for me at least isn't he `-u apache` but rather knowing that `apache` exists as one of the installed services on this box.

In the old ways, that was apparent because of the presence of the log file.

Granted, this isn't the problem it used to be for us, however, it would come up because we'd have our services named things like `foo-ws` and knowing that `foo-ws` existed on a given box might be tricky were it not for the log files.

tadfisher
5 replies
21h38m

    journalctl -f -u <TAB>
Shows you all installed units if you have working shell completion, or 'a<TAB>' gets you all units starting with 'a', etc.

amaterasu
2 replies
19h24m

In which shell?

ac29
0 replies
18h25m

Works in fish, I'll have to remember that one

vbezhenar
0 replies
7h27m

With `ls -l` I can see file modification dates. How do I do it with journalctl? And why do I need to that that in the first place?

Journald would be perfect if I didn't have to know a thing about it. Work in background, move stuff from stdin/stdout to /var/log/journald/service.log, move old stuff in /var/log/journald/archive/service/2024-04/15.log.gz. I'd be happy. Why do I need this cryptic CLI I don't understand. It brings nothing but pain.

foxhill
0 replies
8h47m

correct me if i’m wrong, but i believe the point that is trying to be made is;

a system user/admin has an intuition about files. saying that ‘journalctl -f -u’ (fu, indeed :) and whatever else is inherently undiscoverable, and is a.. basically orthogonal mechanism for handling what should be a simple task. i.e., viewing some logs. it’s far easier to compose and extend from files (what if i only care about the mtime of the log, for instance), than this.

look, i think systemd isn’t.. terrible. i also think it’s suffered a bit of complexity fetishisation, and it seems as though that this resulting complexity may have become invisible to you.

run0 doesn’t seem like a bad idea. but i am wincing a bit at the thought of unrestricted javascript determining access control.

tapoxi
1 replies
21h54m

I mean "systemctl status" shows all services and their hierarchy, there's also "systemctl list-unit-files" if you want to see things that aren't part of the current target (runlevel).

It's much easier in the systemd world to see the state of the system, the state of the service, and the logs of a service because it enforces this consistency.

cogman10
0 replies
21h50m

Ah, good to know. I figured it might be the case that I just needed to RTFM.

kbar13
1 replies
21h4m

honestly that's such a niche problem to have that i dont think it's worth throwing the baby out with the bathwater. anyways you shouldn't be discovering installed services by logfile presence, it should be something like querying your package manager.

rixed
0 replies
13h36m

I wouldn't say it's a niche problem. I also miss being able to go to /var/log and see instantly what's going on.

There should be a command like "journalctl --top" that would list all logging services with amount of logs, oldest and latest log times, and last few lines of each, to improve that experience. Maybe there is already a way to do something similar?

pcthrowaway
0 replies
12h40m

`systemctl list-unit-files` is too difficult?

cduzz
8 replies
20h54m

I appreciate that someone's invented shoes you inflate and snap. I can see some advantages.

That said, when I'm in a hurry and going to do a thing that I've been doing every day of my life, I'm really not a big fan of having to stop what I'm doing and reexamine a tool I've used all my life to figure out how to use it. I learned this stuff decades ago and I'm not anxious to relearn how to do it for a fractional improvement, and I'm not even really 100% sure that this new "inflate and snap" shoe model is actually an improvement, except for very specific use cases.

acdha
7 replies
20h24m

Don’t think of it as relearning a tool, think of it as learning one tool which works for everything. You no longer have to implement your own log rotation, compression, etc. or work out which configuration each program needs to do that in the manner you expect – for example, “is it safe to rotate a log file?” requires you to know implementation details on each program.

llm_trw
6 replies
14h54m

think of it as learning one tool which works for everything.

For how long?

I've been around for decades at this point with people telling me how the newest and greatest thing will obsolete everything that came before it.

The best way to look through logs is still to materialize them in as text in a files hierarchy and use find with grep to look for issues.

olddustytrail
4 replies
12h24m

For how long?

Debian switched to systemd about 12 years ago, so at least that long.

cduzz
2 replies
10h33m

A quick google indicates that it was made default in debian 8 in 2015, which is 9 years ago, not 12.

Perhaps it was available prior to then, but so were daemontools, upstart, and probably a variety of other alternatives.

olddustytrail
0 replies
1h31m

Yes, you're right. I saw when it was added not when it became the default. Still 9 years suggests it's not going to disappear overnight!

acdha
0 replies
1h51m

One thing to remember is that a lot of people use the testing distribution so they would have seen it before the Debian 8 release changed the default. The debate in the community took ages but one factor in concluding it was that people were using it for years without it being anything like the more hyperbolic predictions some opponents made.

llm_trw
0 replies
11h49m

Find came out in 1974.

acdha
0 replies
8h9m

I’ve been doing this for decades, too, but I don’t miss having to deal with everyone inventing multiple log hierarchies, different rotation conventions, compression strategies, etc. not to mention all of the other things which systemd removed from daily toil around process management.

saghm
5 replies
22h34m

journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there

Yeah, this is a bit of an odd complaint. If I were this bothered by having to type those, I'd just make an alias to "journalctl --follow --nopager"` and would have forgotten about it years ago.

stoperaticless
3 replies
22h14m

Never tried it, but if the complainer wrote: tail -f *.logs

Which involves glob’ing. I assume it allows to monitor several services at the same time.

Can systemd do that?

tapoxi
1 replies
21h59m

Yes, journalctl -u postgres -u redis -f etc

mintplant
0 replies
21h50m

Or just `journalctl -f` to follow all logs.

_flux
0 replies
21h51m

It's the basic function what journalctl -f does by default: follow the global log all jobs write into. -u etc are for filtering that.

mdaniel
0 replies
22h6m

I'd just make an alias to "journalctl --follow --nopager"` and would have forgotten about it years ago.

You sure would have forgotten about it when you tried to get onto another machine without the magic set of aliases

I am also prepared for someone to chime in that "log egress tools exist" to move up the Maslow's Hierarchy of Log Needs

citrin_ru
1 replies
20h37m

'journalctl -u service -f' takes many seconds to start showing logs (even with 4GB journal size limit which not that much). 'tail -f /var/log/service' works without a noticeable delay (be it 1kb or 100Gb log file). For me it's a huge regression.

rezonant
0 replies
20h21m

While I'm very pro journalctl, this is very true. They should put some work into the initial read performance on big journals.

hmmm-i-wonder
0 replies
2h23m

This and many other discussions misses the point that most people that don't like systemd have with it.

It can largely do everything it replaces, but differently, in some cases with improvements. Every year it increases its scope of 'problems' its solved.

But the issue is it hasn't _ACTUALLY_ solved a problem for me in about a decade, its only introduced problems. Its replaced things that worked perfectly for me and millions of other users for years/decades with something that... also works... but differently. Now to accomplish the _SAME_ outcome without any personal benefit I have to re-learn their new and usually opinionated way.

There was a time I could log into a system, find logs, parse dates and do everything in these discussions reletave to logs, rotation. Regardless of service because the standards were close enough and the basic tooling (tail/find/tar/grep/awk etc.) worked everywhere always, and you never had to google even if the service was one you never worked on before.

For systemd its the opposite, its almost a guarantee you have to google something along the line when interacting with new systems and services. And as soon as their newly enforced opinions and way of doing things is getting comfortable they go and replace something else that was also working... perfectly fine.

If it actively solved problems for the majority of users we wouldn't hate it so much. Instead it requires more mental overhead than anything other than XORG to deal with and constantly manage than anything else in the linux ecosystem.

SoftTalker
0 replies
15h47m

Not my memory at all. In almost all cases the logs were in /var/log and written by syslog. Unless the whole service was in a chroot directory, or the program was written by an amateur who didn't follow logging conventions.

Asmod4n
0 replies
20h47m

Oh the joy it is to have a corrupted log file which the program that wrote it refuses to even read.

Once you deal with that you’ll realize journald is just in the way and needs to be modified to output a human readable log by default.

superb_dev
23 replies
23h12m

The follow argument is identical to tail `-f`. `sudo journalctl -f -u <service name>`

rangerelf
22 replies
22h52m

And what would be the equivalent to, "Oh, I don´t know the name of the log for this process I can see in 'ps aux', let me cd into /var/log and see what filenames I can find ... or grep everything until I can find a couple of words that make some sense so I can keep digging further"?

The lack of explorability in journalctl, the "need" to keep everything locked behind their own flavor of tools and magic file types, is what makes the rest of us abhor them.

Brian_K_White
9 replies
21h43m

These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem.

The problem with systemnd is it assumes that it's possible for all needs to be predicted and accounted for ahead of time. While "look around at directories and files, and grep within them" works after the fact without any special knowledge or tools. The person who wrote the log file did not need to know how someone will maybe try to access it 23 years later on a different OS. It's just a regular file that can be read by anything over any kind of channel on any os. The person finding themselves needing to read the file does not need to have any particular command installed, or installable, or runnable. It does not require the happy path in order to work.

I have a joke I always say, often self-deprecating making fun of my own self for the way I do things sometimes, but also when I'm trying to commiserate with a customer so they don't feel intimidated by "the expert" or "the engineer": "37 easy steps!"

Every answer that starts with "it's simple, just journalctl ..." is FUCKING 37 easy steps. The very name of the program itself is a trainwreck. journalctl... it takes me 18 seconds just to type it.

systemd is great for managing exquisitely washed masses of drone vms. It's utter and complete shit for direct administration, operation, development, debugging, flexibility, or custom integrations.

robertlagrant
5 replies
20h54m

These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem.

No they don't. They are good answers. If you want answers to a more general problem, then ask. This is not an emotive topic.

Brian_K_White
4 replies
20h41m

They may be correct answers, in that they accomplish a task.

They suck in that the proposed method for accomplishing the task is a suck-ass downgrade from the previous ways the new way proposes to displace.

I beg to differ about emotive, because absolutely the other side of this fence behaves every bit as butt-hurt when challenged as I just did. You yourself just said these crappy commands were good, as a purely unfounded assertion. They are great because you just say they are great. That is even less objective than my rant. I at least explained what exactly I find so bad. Tell me more about not emotive.

robertlagrant
2 replies
20h34m

You yourself just said these crappy commands were good, as a purely unfounded assertion. They are great because you just say they are great. That is even less objective than my rant. I at least explained what exactly I find so bad. Tell me more about not emotive.

Very well: I didn't say the commands were good or great. If you attempt a little objectivity you'll see it.

Brian_K_White
1 replies
20h7m

If you attempt a little objectivity, you will see that addressing the answers (vs the commands) was in my first response.

Before even going into the nature of the commands, I said that the answer does not match the question. The answers addressed details, while the details in the question were merely examples.

Missing the point is actually merely one of the at least two dimensions along which the answers suck. Thank you for reminding me about that.

robertlagrant
0 replies
19h34m

The answers addressed details, while the details in the question were merely examples.

No, the answers addressed the two scenarios in the question. That's why they don't "SUCK". They are good answers to the question as asked, and not the question as you dreamed it. If you spent ten words on asking the question of your dreams, rather than having a go at people for not answering it (whatever it is), you might have an answer.

sunshowers
0 replies
17h14m

To be clear -- you can just dump out all the logs to text and then use your standard grep toolkit on them. You can also dump them out to JSON, and use jq on them -- something you can't do with text logs on disk.

And as far as learning the options goes, learning the basics of systemd and journalctl is much easier than learning how to, say, use a source control system effectively.

(And it's definitely worth trying out new source control systems -- for example, I think most people should at least check out Jujutsu, and many people are going to like it more than Git. As simple as Jujutsu is to use, learning it takes a lot longer than learning journalctl.)

superb_dev
0 replies
15h7m

I didn’t answer the general question because I don’t care, I have no dog in this fight. Im just happy to provide information.

I like systemd and have found it extremely useful. If it doesn’t fill a need for you then use something else.

sgarland
0 replies
19h16m

Agreed. I’ve tried to get used to it on Debian 12 for personal VMs. I just can’t. I don’t care. grep and awk are always going to be available, and I know how to use them.

rcxdude
0 replies
9h25m

It's way better than the previous status quo: now, more or less whatever distro I'm on, there's one command which answers that question directly, not a process of guessing how this system happens to be set up. You can guess and grep through most any kind of problem, but I don't see why anyone would want to do it as anything but a last resort, and to me that fits '37 easy steps' far more than the 1 consistent step in these replies (notice how none of them say 'oh, but on debian...'?).

superb_dev
4 replies
22h15m

Well `-u` refers to the unit file, so I would start with `sudo systemctl status` which lists the status of active unit files. I bet I could find the unit name I'm looking for there. If not, then `sudo systemctl list-units` should have it. (and you can grep the output of both)

Systemd and Journald are less opaque than I used to think. Even if you don't want to learn the commands, all of its unit files (and the relationships between them) are available through the filesystem. Most of your unit files will be in `/etc/systemd/system`, and the active relationships between units are expressed through soft links.

aeonik
2 replies
18h53m

How would you exclude certain units from your logs? Let's say that Auditd is spamming your logs, and you just want to exclude those?

Can you filter on search? How do you prevent applications from writing to Systemd at all?

superb_dev
1 replies
15h13m

I would start with `man systemd`, or maybe `journalctl —help`.

If you don’t want a service to log to systemd, then don’t run it in systemd?

pcthrowaway
0 replies
12h35m

I think you can also configure the journal per unit right? Don't remember how exactly, at the very least you can stream logs to a different system.

There are also services which will just use their own logging convention for some reason. Honestly it's easier just to go with journalctl for everything you can.

ramses0
0 replies
16h45m

systemctl does not have the Unix nature.

iforgotpassword
2 replies
22h45m

Huh, isn't grepping journalctl output pretty much the same? It even prefixes messages by the binary name.

mdaniel
1 replies
22h5m

Pedantically, they're the unit name which only sometimes matches the binary name

rezonant
0 replies
20h14m

Actually no, they are prefixed by the binary name and the PID number. Technically they are prefixed with: `<date> <host> <binary>[<pid>]`.

You can then use `systemctl status <pid>` to identify the unit if you need to.

I would imagine this is configurable, and this might be the configuration chosen by my distribution (since I have not changed it myself). It would actually be nice to show the unit name instead of the binary/PID combination, though not strictly necessary.

EDIT: Ooh, systemd 239 adds `journalctl -o with-unit` to do this exact thing. There are lots of other formats you can choose from as well.

EDIT 2: Unfortunately there's no way to set this as default, you must use `-o with-unit` each time or set up a shell alias :-\

sunshowers
0 replies
21h44m

You do have to learn a few new things, yes. But it's not too difficult. We all have to learn new things sometimes.

I spent around 15 minutes a few weeks ago learning how to do a few things with journalctl, and I came away from it with a great appreciation for its power.

rcxdude
0 replies
21h31m

systemctl status <pid> will show you the unit and helpfully the last few lines of log from it. Journalctl -u <unit name> will then show you the full logs

JoshTriplett
0 replies
19h33m

Oh, I don´t know the name of the log for this process I can see in 'ps aux',

With services using journald, there's no "name of the log" because everything's in the journal, so that part isn't a problem. Rather than "is this in auth.log or syslog or thisservice.log", it'll always be in the journal.

let me cd into /var/log and see what filenames I can find

You can filter journal entries by unit (-u) or by service identifier (-t). Often, though, I find it really useful to be able to see the adjacent entries from other services at the same time, since that can give some indication of what's happening on the system that caused an issue.

or grep everything until I can find a couple of words that make some sense so I can keep digging further

journalctl --grep, or more conveniently, journalctl and then / to search.

The lack of explorability in journalctl

It's explorable by dozens of different axes, and if all of those aren't sufficient, you always can get the whole thing as text and run any command you like on it, or get it in structured form and do structured queries on it.

sunshowers
3 replies
21h46m

I've recently become a fan of the `-x` flag to journalctl, which adds additional context to log entries and even suggests remediations at times. I've identified and fixed several issues on my Linux systems that way. Kind of hard to get that with tail -f!

rezonant
0 replies
20h20m

Ooh nice. What are some examples of things it will catch?

dumpsterdiver
0 replies
19h55m

My goto is journalctl -xf. Best of both worlds :)

aeonik
0 replies
19h35m

How does it work? Can I pipe non-journald logs into the -x flag to take advantage of this lookup?

hughesjj
1 replies
23h8m

My 2c, I definitely prefer systemd boot+networkd, fine with journald, don't use the others enough to have an opinion.

iforgotpassword
0 replies
22h42m

Same. Init system is awesome, love .ini files, networkd is as simple as it can be, journald is fine. Love systemd-nspawn for simple containers as it feels more lightweight than docker. Especially for quick one-offs where I don't need isolated networking you basically have chroot on steroids with "systemd-nspawn -D /path/to/fstree".

rezonant
0 replies
20h31m

This was a really big pain, yes, but I also remember how I could `tail -f *.logs`.

Others point out that journalctl supports `-f` and `-n` for determining how much journal to return, but for me what's great about journalctl is that I do not need to know where the program is logging to, how it rotates logs (or how it doesn't), or anything else. The program does not need special permissions to a log location in /var/log or /usr/var/log or ~/... or anything else, it just outputs using stdout and it gets captured. When I want to look at logs, I just use the same moniker that I use to control the service: its unit name. It is so incredibly nice- I do not want to go back to the bad old days of spelunking through /var/log and friends.

--no-pager

To be clear, if you pipe journalctl somewhere, it will automatically skip the pager and just work. `--no-pager` is most useful for when you want to print some unpiped content in an automated script to avoid having a non-existent user exit the pager.

ranger207
0 replies
19h37m

I remember, and sometimes still have to deal with, programs that _didn't_ dump their logs in /var/log, forcing me to figure out where the log are in the first place

jordemort
0 replies
22h13m

systemd-nspawn is actually pretty great, and is mostly just a tool that exposes functionality that systemd already needs for other reasons. IIRC it was originally developed to aid in testing systemd itself, and was initially shipped as an unsupported extra in case other people found it useful.

systemd-resolved is the only way I've ever been able to get dockerd to play nice with Tailscale DNS; it's also the best way that I've found to get a system to pick different upstream DNS servers depending on domain. The alternative is hand-rolling it with dnsmasq or something similar.

I admit I haven't really seen a huge advantage to using systemd-networkd over NetworkManager yet, but for servers with relatively static network configurations, I greatly prefer systemd-networkd over any of the various implementations of ifupdown.

SoftTalker
0 replies
15h51m

Those old init scripts were pretty boilerplate and not that hard to write. And in the case of OpenBSD (and maybe other BSDs?) the scripts for /etc/rc.d are usually just a few lines.

With the traditional init system I knew what was going on, and if I didn't, find and grep were your friends. With systemd I'm googling everything every time. The systemctl man page is over 1,100 lines. OpenBSD's rcctl man page is 119 lines.

I'm sure there are use cases for systemd but for running a server that provides a single or a handful of services, it seems like complete overkill.

mid-kid
8 replies
1d10h

I'd agree with your message if systemd was just an init system.

bryanlarsen
7 replies
1d6h

It's not difficult to use some parts of systemd without using others. Is it any different than something like coreutils, another package of linux utilities that are synergistic but usable seperately? Nobody complains about coreutils being bundled. Even the rewrite in rust crowd bundle them.

jacoblambda
5 replies
1d2h

It really is not. This "sudo replacement" (which under the hood is systemd-run) will apparently require quite a bit of the systemd stack to operate. That is not something you have access to in many lightweight container distros or on other non-systemd distros.

And coreutils is expected because most people use GNU/Linux. Coreutils is that GNU userland part. And either way, the majority of coreutils are GNU implementations of standard unix components. You can use most software that depends on coreutils on other *nix platforms like BSD for this reason.

bryanlarsen
4 replies
1d1h

I doubt you'll need to run systemd as pid 1 to use this.

navaati
3 replies
23h42m

Oh you do: this work completely differently from sudo, there is no suid binary involved, instead it does IPC to the systemd pid 1 and asks it to spawn you process, attached to your current terminal. So if you don't have systeme as pid 1, it'll have noone to talk to.

Whether you like that or not is for you to decide.

bryanlarsen
2 replies
22h41m

IPC will likely be over d-bus. The new process will fork off a systemd which is almost always pid 1, but it might not have to be.

dijit
1 replies
18h24m

are there any non-systemd DBus options anymore? I had a hard time a year ago setting up Gentoo because there were no maintained options at that time.

jacoblambda
0 replies
17h42m

There are. Gentoo has actually always used the FreeDesktop reference implementation instead of sd-bus (the systemd implementation).

FreeDesktop also maintains a list of implementations (also including bindings so you have to read to find which ones are full impls vs libdbus bindings).

https://www.freedesktop.org/wiki/Software/DBusBindings/

j16sdiz
0 replies
11h32m

No. The real nightmare is systemd integration with dbus.

esoterae
6 replies
23h37m

No, it hasn't.

You forget, the reason systemd was originally rationalized for its insertion into our trees was "boot times are too slow". Its chameleon-like nature and ability to solve the hastily described problem du jour seems to be its only consistently touted feature.

Bash scripts that start processes are ephemeral. If it's signal handling you want, that was your program's problem. Either that or your program didn't fork itself, which is a fish of an entirely different feather.

And now we have this sprawling mess of complexity and headache.

riddley
5 replies
20h22m

Same thing is happening with Wayland. It reduces features adds complexity and solves no new problems but here it comes.

themerone
3 replies
19h32m

How is Wayland more complex than X?

gmueckl
1 replies
17h59m

The resulting wayland environments are more complex because wayland itself refuses to define/include features that desktop systems are expected to have. This results in a sprawling mess of competing and incompatible interfaces for those gaps that other parts of the implementations (desktop environments) now have to compensate for by including multiple implementations of the same thing based on all these different interfaces.

imtringued
0 replies
8h51m

Stop using the wrong words. You're saying Wayland is too simple and feature incomplete.

j16sdiz
0 replies
11h30m

Wayland by itself is simplier -- it is done by "outsourcing" everything a window system should do to the window manager. There is where the complexity kicks in.

roenxi
0 replies
18h43m

Wayland was a mis-fire in terms of user friendliness for the first decade or so. But it is still a big step up from the mess that was a typical xserver back in 2010.

It reduces features adds complexity...

The irony here is Wayland is part of a huge effort to decomplex an xserver into component parts. A really commendable initiative; the path forward while maintaining the X protocol probably was impractically hairy.

The Wayland protocol design had some glaring flaws, but saying that it adds complexity is unfair. It oversimplified; it would have benefited from some flexibility in providing a standard mechanism to let people inspect the buffers graphics buffers to be composited.

hxelk1
5 replies
1d10h

you can actually declare startup dependencies and other useful relationships

In theory, yes. In practice, I had a lot of trouble ordering things correctly in non-trivial cases.

it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back"

I can only speak for myself, but I don't want the abysmal sysvinit scripts back. I just want a simple process supervision suite which is true to the UNIX way of doing things. The sysvinit/systemd dichotomy is false.

Runit and s6 are both very real alternatives to systemd. They lack a ton of features, but they are a way to reliably run services. They do use shell scripts, but not for the reasons sysvinit did. They are extremely simple and have a very small attack surface as a result. Runit itself is a spiritual descendant of daemontools which predate systemd by great many years.

The problem with systemd is that it's a mediocre solution to many problems. UNIX deserved better.

[Edit: whitespace]

jauntywundrkind
2 replies
1d4h

The other pieces are also pretty excellent. Ifup gave me no joy & was very limited. Systemd-networkd is a wonderful option with vast & great capabilities, that meshes well with the init process & it's style. Systemd-timesyncd is fine, I dunno, works for me. Systemd-journald is probably the weakest of the batch but mostly because it's not very ambitious; I loath that there's no way to really deal with super-active programs hogging all the logspace, short of configuring a second journald instance for that program, which ain't no joy to setup. Systemd-home is a cool set of features for portability. Systemd-nspawn is a bit ahead of its time & looks a little weird now but was a very novel & powerful thing to have built in to most systems. Systemd-resolved is a pretty good local DNS that handles mdns and much weirder cases easily. Systemd-boot is a really nice easy to work with uefi boot loaders that's worlds easier to deal with than uboot or gasp grub.

All of these are taken em or leave em. But they're good expectations to have. I love the bazaar model, but Linux used to have so few common expectations, used to manage various bits so poorly. And now there's a much better base of capabilities, which have universal patterns of management that tend to apply to them (how etc files are laid how, being dbus and maybe varlink accessible). Linux hadn't been growing; when you came to a random systems you expected enormously little and typically got it, and what extras were available were scattered/random and often not particularly high quality or capable software. Systems has extended a much bigger base of competency & capability. That we can plug in a USB drive and systemd-home can create an isolated dynamic user out of that & let that user securely run their environment there is a neat as heck expectation. That our network manager supports setting up such a wide range of bridges and tunnels and taps and tuns is fantastic, is excellent. I don't have words for people turning their noses up at this better world; this is so much more competent & capable a world than where we were, gives us so much we all can now take for granted, and it's been done smartly, more mono-repo than monolithic, such that you can do alternatives. But many of these pieces are utterly without peer. And the consistency of operation you get, the predictability of use, from being under the same umbrella, is an ergonomic wonder that is unmatched.

ghostpepper
1 replies
1d2h

Is there a good overview of these pieces and what they're responsible for and how they fit together?

I had a quick skim of the docs on systemd.io and there are quite a few documents but they don't seem particularly organized and I couldn't see a good architecture overview.

mattpallissard
0 replies
23h21m

I hate to be this guy but the man pages have it all

  man -k systemd

There's some terminology to learn, but overall it's pretty approachable.

Edit; and as far as architecture goes they are all _separate_ programs. It's not a single large "systemd"

mid-kid
1 replies
1d9h

In a similar vein, systems like openrc use "shell scripts" as well, but can generally be written declaratively[1]. This provides greater flexibility when it comes to creating one-shot services or services that require a little setup before running, as you can just re-define the start() function, rather than requiring one to make a separate shell script for it, or dependency tree, like you'd have to in systemd land.

"sysvinit" is an ill-defined concept, anyway, as every distribution had their own scripts and tooling around actual services, and sysvinit was generally only responsible for starting getty and launching the distribution's actual service system. How initscripts were created and how you managed them depended significantly on the distribution.

[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-vpn/tails...

declarethroway
0 replies
14h38m

Debian's sysvinit scripts can also be declarative. https://github.com/DanielAdolfsson/ndppd/blob/master/ndppd-i...

The full system also cares about dependencies and parallel running. And this is not recent, but the black legend will never die.

Bonus: by having the shipped scripts under /etc, tools like etckeeper can show your changes as well as updates, all in one place.

Faaak
5 replies
1d10h

Yeah, basically I've found that the people the more vocal against systemd are either not really knowing how it works behind the scenes, and just criticizing for the sake of it (or because other people do so), or criticizing from an ideological point of view (do one thing and do it well). They see systemd as an octopus, not following the unix ideology. Which I don't really agree tbh

jacoblambda
3 replies
1d2h

The issue is that it's not just ideological. "Do one thing and do it well" is important because if you want to port software to another platform, it's a lot easier to port a single dependency component over to make it work than it is to port over the entire framework.

This is a serious problem and it makes it way harder to make things cross platform.

Xylakant
2 replies
23h3m

Systemd was written specifically for Linux, hard depends on a list of features provided by the Linux kernel and leverages them to do its work. Porting it to another kernel is a rewrite. Lack of portability is in this case a design tradeoff.

jacoblambda
0 replies
22h26m

Sure that is the case for systemd itself but it's not the case for most projects that happen to use things systemd provides.

There is very little benefit for most userspace software to tie itself to systemd and by extension linux when otherwise it could be portable to any unix or unix like platform. Especially when an alternative, portable solution already exists and is well established.

fhars
0 replies
22h26m

The argument was that this design of systemd makes it hard to write applications that are portable, so that systemd is effectively a very big net negative to the open source ecosystem, because it causes massive fragmentation.

dijit
0 replies
18h14m

I think this is a really old statement. I’ve used systemd since it was made default in Fedora back in 2011 (Lovelock, anyone?) - at what point am I qualified to have an opinion, after having used it personally for 13 years and professionally for 8.

systemd is scary for 3 reasons.

1. it is inscrutable. Debugging it is nearly impossible, so you had better hope you don’t get a buggy release, especially with how hostile the devs can be.

2. it is large, and growing. Lots of things it claims are optional are in reality: not really. This is fine until uou get something that really doesnt work well (systemd-resolved is consistently the largest reason I have connectivity issues, wether it be because it interferes with docker inter-container networking or because it needs to time-out when trying DNSSec to continue- or if it fights with my vpn provider for power over my resolvers etc). Due to my distro being very tied to it: I gotta keep using it and working around it.

3. The interface is irreplaceable. Why are their 13 init systems? Because init is a closed scope. To be a sucessful init you need to spawn processes and do it cheaply. Supervising processes after start? Noble, and there were implementations that could do that (CDDL licensed SMF from Solaris for example). However we have already reached the state where it will be literal man-decades of work to replace systemd as we will need to make any replacement bug compatible with systemd itself. Its the ultimate show stopper.

The implementation is the reference. Which is a large departure now from what came before.

dcow
4 replies
1d10h

I love systemd.

andrewstuart
3 replies
1d10h

Me too. The best thing about Linux.

jbverschoor
2 replies
1d10h

It's a re-implementation of Apple's launchd. I've always liked it though

freedomben
0 replies
23h26m

It is much more than just a re-implementation of launchd. I can't grab a link right now, but Lenart wrote a long blog post about the philosophical decisions behind systemd, and he goes into detail about what he liked from launchd and what he did not like. It is called "rethinking PID 1"

bryanlarsen
0 replies
1d6h

A much improved version of launchd, yes.

paulddraper
3 replies
23h1m

100%

Systemd unit files make Linux feel like a rational OS.

slackfan
2 replies
22h51m

Only if your marker for a rational OS is NT.

delta_p_delta_x
1 replies
21h51m

Not the parent commenter. Windows has a lot of rubbish user-level interaction which belie how good an OS NT really is. Anyone who blindly disses it because 'Windoze' and 'M$ bad' is not really worthy of any attention whatsoever.

slackfan
0 replies
19h39m

NT isn't terrible with some very well designed systems, that is quite true. It is however good for a completely different list of reasons that *nix is. Trying to conflate the two is a pottering's errand.

foresto
3 replies
20h4m

systemd has been a net positive for the linux ecosystem.

You're presuming to speak for an awful lot of people there, on a topic that would be difficult to measure.

since the beginning of systemd people have moaned

it's quite annoying that the armchair linux experts complain

Now you're overgeneralizing, and doing so in a dismissive and patronizing way.

Here are a few examples of problems I have with systemd:

System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted.

Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope --property=Delegate=yes <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable.

At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back.

There are more examples, but I'm tired of re-living them and don't really want to write a book. I hope these few are enough to convey my point:

Systemd has been a net negative in my experience. It has made my life markedly worse, without bringing anything I needed. Based on conversations, comments, and bug reports I've seen over the years, I get the impression that many others have had a similar experience, but don't bother speaking up about it any more, because they're tired of being dismissed, ignored, or shouted down, just as I am.

I would welcome a reliable, minimal, non-invasive, dependency-based init. Systemd is not it.

imtringued
1 replies
8h43m

Systems isn't blocking the shutdown. Systems is being blocked by a service. Since you are saying that you can't track down the exact service, you must be using a container runtime like docker or LXC which is not transmitting the kill signal properly to the container to shut it down. The container itself then keeps running for whatever reason. This entirely depends on your particular setup and has very little to do with systemd.

foresto
0 replies
8h3m

Since you are saying that you can't track down the exact service,

That is not what I said.

evertedsphere
0 replies
8h11m

It offers no manual skip option

ctrl-alt-del skips iirc?

aftbit
3 replies
22h9m

Ah yes I remember back when you just put the system hostname in /etc/hostname. Now we have hostnamed!

egorfine
2 replies
21h58m

Which is now borderline impossible to tame. Google "change hostname ubuntu" and take a look at the results and comments.

pcthrowaway
1 replies
12h29m

I'm still trying to figure out whether I like nftables more than iptables. Both are pretty complex to manage IIRC (I've only touched nftables a couple of times though, and not recently)

aerique
0 replies
6h39m

Well, it has "NFT" in the name so it must be good!

bitwize
1 replies
21h11m

I don't resent systemd for existing, but I don't want to be forced to accept Lennart's shitty design decisions and it's clear he wants me to be since he successfully agitated for other critical components to hard depend on it. I want the option of opting out, which Lennart would deny me if he could.

At the end of the day, I just run Void (or MX Linux if I want something more Debian-flavored) and get on with my life.

aerique
0 replies
6h39m

Void Linux and now Guix have been a godsend.

xolve
0 replies
1d8h

Its refreshing to see that just hate systemd because "its not UNIX way" is not anymore. I see better discussions under this post and in other places around the web.

ranger_danger
0 replies
1d2h

systemd has been a net positive for the linux ecosystem

I guess that depends on whether or not you consider the great number of CVEs caused by it don't matter enough.

nextaccountic
0 replies
19h13m

systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it?

Systemd was meant to replace Ubuntu's upstart, not sysv init. And it indeed systemd was better designed than upstart.

Sysv init is a horrendous hack. People should NOT use that. Upstart had limitations but is okay, and certainly much better than sysv init. Systemd is okay too (but has much more features).

Also as an historical note, both upstart and system was inspired by Apple's launchd.

NixOS was an early adopter of upstart but it later migrated to systemd (alongside Ubuntu itself)

SixDouble5321
0 replies
1d8h

Systemd isn't just one thing lol

constantcrying
74 replies
1d11h

Why do they have to do this? This is really, really stupid.

My issue isn't even that someone tries to replace sudo. That may or may not be a completely fine thing to do, depending on the state of sudo and what improvements can be made. But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none.

This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason.

I am very glad to have jumped ship from systemd. It is particularly bad software created by a team of people who engage in very bad practices and a totally unhealthy view of software in general.

dale_glass
12 replies
1d10h

But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none.

You should look at it differently, and then it'll make perfect sense.

systemd has long stopped being just an init system. It's a system tooling suite. When thinking about systemd don't think "PID 1", think "Linux New System Software Suite". It's a big umbrella project in the style of Gnome and KDE.

For example, systemd-boot is a perfectly normal bootloader that's just been systemd-themed. It has a "ctl" tool, has the same command-line aesthetics as other systemd-group tooling, and so on. It's not in any way dependent or even interested in the init system.

constantcrying
11 replies
1d10h

systemd has long stopped being just an init system.

I think that this has always been the core criticism of anyone who objects to them. Besides systemd, the init system, just being very poorly thought out.

dale_glass
10 replies
1d10h

What's poorly thought out about the init system? It's not perfect for sure, but on the whole I don't have any issues with it.

constantcrying
9 replies
1d9h

How much time have you spent writing and debugging systemd init files?

dale_glass
8 replies
1d9h

I've written a fair amount. Nothing much to debug in most of them.

constantcrying
7 replies
1d9h

Riddle me this: can I create new mount files inside a systemd unit and have them activated to mount the locations specified? Do I need a daemon reload, for this?

dale_glass
5 replies
1d9h

That sounds like a job for systemd.generator.

I don't think having an unit that generates units at runtime is an officially supported use case, since generators exist.

constantcrying
4 replies
1d9h

This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help.

I don't think having an unit that generates units at runtime is an officially supported use case

Are you sure? Can you tell me how I would find out?

dale_glass
3 replies
1d8h

This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help.

That's the point. Any situation in which you have a system modify itself at runtime is a recipe for a headache. So you do your auto-generation first, then work from a stable state.

Are you sure? Can you tell me how I would find out?

Aside from that this kind of recursion seems like a great way to get weird problems, and that generators exist for this exact thing, the whole design of systemd discourages this kind of trickery. Units are just supposed to start a command and little else.

Maybe somebody made an official pronouncement on this somewhere, but my personal take on this kind of thing is that it's a bad idea, anywhere, not just systemd.

constantcrying
1 replies
1d7h

So you do your auto-generation first, then work from a stable state.

You can't do auto generation if that generation depends on the output of some units. Generators can not solve that problem.

Units are just supposed to start a command and little else.

What a bizarre thing to say. No, that is not just what units are for. I think you are severely misinformed about what systemd is. Units are supposed to take care of ordering accept IPC, define how to handle failures and manage devices.

That comment alone makes me believe that you just do not know what you are talking about at all. It completely misses why systemd is designed the way it is and what it tries to accomplish.

dale_glass
0 replies
1d7h

You can't do auto generation if that generation depends on the output of some units. Generators can not solve that problem.

True

What a bizarre thing to say. No, that is not just what units are for. I think you are severely misinformed about what systemd is. Units are supposed to take care of ordering accept IPC, define how to handle failures and manage devices.

I mean that part of the point of systemd is that units mostly work out to ExecStart=/usr/bin/binary, and an unit isn't supposed to contain the arbitrary jank one can put into a SysV script.

IPC and the like is an explicit systemd feature, not something you improvise behind the scenes and then expect to work anyway.

rascul
0 replies
1d5h

Units are just supposed to start a command and little else.

Units are not just for services.

From systemd.unit(5) man page:

A unit file is a plain text ini-style file that encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd(1), a resource management slice or a group of externally created processes.
Spivak
0 replies
5h25m

Yes you need a daemon reload to discover the new unit files. Is there in issue with doing this? A reload means reread its config, it's not a reexec.

Jonnax
12 replies
1d10h

Is that really how they develop software?

Because I'm pretty sure that most of the components are optional.

You did not even discuss the reasoning given for not using sudo to instead hop on your soapbox to say it's bad software with bad practices and that they are stupid.

It's annoying how in the the more surface level Linux communities there's 0 value in discussing systemd.

"1 million lines of code for PID0!"

The new thing is blaming systemd for that recent exploit even though distros were patching in the bug themselves.

People analysing the exploit determined that a new version of systemd was going to prevent the exploit vector so the exploit seemed to have been rushed out.

Isn't this just textbook FUD?

What I've noticed is over the years is systemd would have identified a gap in functionality.

Like systemd-homed having a solution for automatically encrypting home directory when the machine is suspended.

Is that a functionality that OSX has had for years? Yes.

But anti-systemd people will dislike it automatically.

constantcrying
11 replies
1d10h

Why are you bringing up random arguments I didn't even make?

No, I am a dedicated systemd hater ever since I spend over a month full time writing and debugging systemd services for work. Systemd (the init system) is just all around badly designed and executed, I have very little confidence in the developers and their technical abilities and their tendencies to expand into completely unrelated areas for seemingly no reason makes me quite concerned.

I wouldn't blame the xz exploit on them, it is very hard to call it their fault in any way. But I do think it is a symptom of a system which has grown far too thin and wide.

Jonnax
10 replies
1d9h

Because your post is the repeating cliches that are under every discussion about systemd.

You're essentially saying that the month you spent is enough for you to call it bad and the creators incompetent.

What qualifies you to make a determination like that?

There is never any actual technical reasons it's always about vague things like not adhering to UNIX philosophy, lines of code or it being badly designed (without any real architectural criticism)

This is an article about why they believe sudo isn't a good system. Where's your criticism of that from a technical / security perspective?

It's been about 10 years since systemd was adopted by Debian/Ubuntu/Redhat/Fedora etc.

Millions of deployments over the years. The companies that build and are paid to support for years with SLAs the operating systems are using it without issue.

constantcrying
9 replies
1d9h

There is never any actual technical reasons it's always about vague things like not adhering to UNIX philosophy, lines of code or it being badly designed (without any real architectural criticism)

I did not mention the first two, so please do not pretend I argued that. For bad design look at transactions. That is really dumb and makes the system near incomprehensible. The documentation is bad, dbus is literally so bad they tell you not to use it without a wrapper. The terminology is very questionable and makes it hard to explain what a unit actually does.

But I don't even see that as the worst part. The worst part is that they fundamentally can't do basic software engineering, in the sense that they do not have a defined project scope. Everything is potentially a systemd issue and not once does anyone take a step back and say "maybe systemd" isn't the right place to fix that problem.

This is an article about why they believe sudo isn't a good system. Where's your criticism of that from a technical / security perspective?

If you don't read my posts please do not respond to me. Look at the first post I made and carefully read it.

growse
8 replies
1d8h

If you don't read my posts please do not respond to me. Look at the first post I made and carefully read it.

I read your OP. It does not contain a technical / security criticism of run0. It's an angry, hand-wavey, vague rant against a project that took a design decision you apparently disagree with, but lacking any actual analytical evaluation of the thing up for discussion.

This sort of top-level post shows up on every single article that mentions "systemd", so you'll maybe understand why people tend to be dismissive.

constantcrying
7 replies
1d7h

I read your OP. It does not contain a technical / security criticism of run0.

Yes, I literally say there is nothing wrong with the idea, so you going ahead and demanding I criticize the idea, is just absurd.

Really, this is completely bizarre. I even say that the thinking behind replacing sudo is fine, yet you are here complaining that I don't deliver technical arguments against something which I even told you might be completely valid to do from a technical perspective. Baffling.

growse
6 replies
1d6h

Let me get this right: you see an article on a new thing, which you have no problem with, but have an angry rant in the comments section anyway? And now you're baffled by people's reaction to that?

I'm not sure there's much point engaging further, I hope you have a good rest of the day.

constantcrying
5 replies
1d6h

No, I think the systemd project shouldn't exist. I have no problem with someone writing a sudo replacement.

Do you understand the difference?

SAI_Peregrinus
4 replies
1d4h

Do you also think the GNU project shouldn't exist? If not, what's the difference?

yjftsjthsd-h
3 replies
22h42m

I can use GNU bash on NetBSD with no other GNU software installed. I can install GNU coreutils on Alpine Linux (complete with musl libc instead of glibc). In fact, it's possible to just install a single part of GNU coreutils but not the rest - ex. Alpine packages just sha512sum as https://pkgs.alpinelinux.org/contents?branch=edge&name=coreu... (not sure why). I don't think I've seen it done, but you could build a Linux distro that used glibc and gcc but no other GNU software (busybox coreutils and ksh shell, say). GNU has their own kernel, but is predominantly used on other OSs. They want to build all the pieces, but you can opt in or out of all of them, and they're all portable. In contrast, if you want to use, say, run0, you must run systemd as PID 1, you must use journald, and the whole stack only runs on Linux. So yeah, that is actually different.

growse
2 replies
20h36m

and they're all portable...

I think that portability is a deliberate anti-goal of systemd.

In contrast, if you want to use, say, run0, you must run systemd as PID 1,

No, you must run something on pid 1 that implements the spec, similar to how musl can be used instead of glibc - they both implement the same spec.

Run0 expects pid 1 to behave a certain way, much like my web browser expects web servers to behave a certain way.

yjftsjthsd-h
1 replies
1h16m

I think that portability is a deliberate anti-goal of systemd.

Yes, and that is one of the things I dislike about it. (In fairness, the list of things I like about it and the list of things I dislike about it are both fairly long.)

No, you must run something on pid 1 that implements the spec, similar to how musl can be used instead of glibc - they both implement the same spec.

Run0 expects pid 1 to behave a certain way, much like my web browser expects web servers to behave a certain way.

If there's only one implementation, then it's not portable. If a webapp uses a web API that only Chrome implements, it's not portable regardless of whether Google published a spec for their non-standard behavior. There are dozens of web servers and web clients that all speak HTTP, there is one systemd.

growse
0 replies
43m

Once upon a time, there was only one web browser too.

zokier
10 replies
1d9h

Instead of just hating based on assumptions it would be useful to actually familiarize with the thing you are critizising

But what makes me really upset is this completely unexplainable need to make everything part of one particular init system

systemd is not init system, its and umbrella project for various core system components, which includes an init system.

There is absolutely no reason to tie your new sudo replacement to systemd

well, in this case there is good reason to have it interact with service manager in general

But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID [...] Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client

strictly speaking it's not 100% coupled to systemd specifically, it most likely uses systemds d-bus API, which is part of their "portable and stable" APIs and as such could be implemented by other service managers https://systemd.io/PORTABILITY_AND_STABILITY/

This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason

The couplings between systemd projects are not that tight, you can pick and choose which parts you want, they explicitly are not "forcing all their projects" to consumers. The minimal systemd build has only init, journald, and udev, which is not exactly sprawling huge. All the rest of the projects are fully optional, and I believe quite many of them can actually work without systemd-init

constantcrying
8 replies
1d9h

Half the people here tell me that systemd is great because it tries to create an integrated complete system, the other half tells me I can just pick and choose.

Obviously one of these groups is lying.

thiht
6 replies
1d9h

Both can be true though, it can create an integrated system where everything systemd-* works together, but where you can replace any systemd-* you don’t like with something else

constantcrying
5 replies
1d9h

The point of an integrated system is that interactions between components enhance the system as a whole. This is obviously incompatible with an easy replacement of components.

This is literally just basic systems engineering. I don't even know what you are arguing here. The more tightly integrated a system is the harder it is to replace individual components.

thiht
1 replies
1d7h

This is literally just basic systems engineering

Well… yes it is. Public interfaces and contracts, anyone? Decoupling?

constantcrying
0 replies
1d6h

The more tightly integrated a system is, the more involved the contracts between the components become. I seriously didn't believe that a single person here would disagree with that.

A component that depends on one simple interface is far easier to replace than one which depends on twenty complex ones. This seems like the most basic stuff.

growse
1 replies
1d9h

You can have a well-integrated system without having tight coupling between components. Interfaces are a thing, and a high level of integration just means having a good collection of interfaces between well-defined conceptual components with well-defined capabilities. The actual software that implements those components is entirely separate.

constantcrying
0 replies
1d8h

I don't know what you are arguing. Replacing a component in a tightly integrated system means that the component has to be compatible to that tightly integrated system, meaning lots of assumptions and replication of functionality.

This means components have to tightly conform to the components they are replacing, which obviously decrease modularity as these components are harder to maintain for available system configurations.

This isn't about whether someone can rewrite a part of systemd, but whether you can freely mix and match, which tight integration works against. Obviously

wmf
0 replies
22h56m

You can replace most systemd components but in that case you have fewer features and probably more code overall. If you run the whole systemd bundle you get more features.

kergonath
0 replies
22h28m

Replace “systemd” with “GNU” and it might be clearer (or “Gnome”, or “KDE”). Yes, they are built to work together. No, they are not monoliths.

mid-kid
0 replies
1d9h

systemd is not init system, its and umbrella project for various core system components, which includes an init system.

The point being made is that it directly depends on the init system part.

well, in this case there is good reason to have it interact with service manager in general

I disagree! There's no reason to not have it be its own daemon with its own configuration and looser bindings to the rest of the systemd ecosystem (e.g. through dbus and other protocols). KDE applications do this a lot, where they take advantage of other KDE components if present. This is strictly a philosophy thing and not a requirement for achieving what he proposes.

their "portable and stable" APIs

"we're portable if you reimplement our APIs", idk how this is an argument. They consistently make very little effort to be compatible with (or provide fallbacks for) what's already there. Having stable APIs is nice but there's a reason most of the interfaces on that page don't have alternative implementations: They solve questionable problems and provide no tangible benefits over the methods there were before. Yet projects feel compelled to hard-depend on them...

The couplings between systemd projects are not that tight, you can pick and choose which parts you want, they explicitly are not "forcing all their projects" to consumers.

In practice they are. The primary reason why everything is shipped as a single project is because that makes it easier to make available in different distros (they just enable everything), allowing it to become the "de facto" standard since it's available everywhere. There's a lot of projects that solve some of the systemd tools' in sometimes better ways, that never see the light of day because they don't have a trojan horse to ride in with.

There's a reason why projects like elogind exist, because there's only a very select few systemd tools that work without systemd at all

dmm
9 replies
1d10h

they will force all their projects simultaneously onto all their users for absolutely no reason.

That's just not true. Just because a system uses systemd the init system doesn't mean the it is forced to use the other components.

constantcrying
6 replies
1d9h

The single beat reason for doing this is to get a coherent complete system. This is what every other person here says.

You can not try to create a large coherent system and then tell people they shouldn't use that particular part. That is totally disingenuous. Systemd is DESIGNED to be an all or nothing deal.

growse
5 replies
1d8h

Systemd is DESIGNED to be an all or nothing deal.

^[Citation needed]

constantcrying
4 replies
1d8h

Again and again people in this thread have told me that the great thing about systems is that it delivers integrated tools.

growse
2 replies
1d7h

And people are also telling you that tight integration is not a mandate. Having a bunch of stuff designed to work together does not mean that they're tightly coupled and can only work with their specific implementations.

We've all got confirmation bias, the trick is to be aware of it.

constantcrying
1 replies
1d6h

This is such a bizarre statement. Of course any system with tight integration demands more precise specifications. Literally systems engineer 101.

This is such an absurd hill to die on.

logicprog
0 replies
1d2h

You aren't making any sense. All of the components of system D are separate programs, and yes they are maintained by the same general project and designed to integrate well with each other, but just because components are designed to integrate well with other components from the same project if they are present, that doesn't remotely mean that all of the components are required. And I mean, the proof is in the pudding, there are plenty of distros that do not use all of the components of systemd. Also, doesn't Linux have a long history of creating integrated suites of programs designed to integrate well with each other and used together? Like GNU?

kergonath
0 replies
22h23m

A lot of people also point out that “integrated” ≠ “mandatory” and that it is not, in fact, an all or nothing deal.

blueflow
1 replies
23h47m

The reverse is true: Trying to use a component like udev or logind or in the future, run0, will require the use of systemd. Either you use full systemd or you can't get any of the fancy stuff.

Gentoo folks have eudev or seatd but thats an uphill battle.

timw4mail
0 replies
23h28m

You can't take OpenRC away from me!

deng
7 replies
1d10h

But what makes me really upset is this completely unexplainable need to make everything part of one particular init system.

It is not unexplainable at all. In fact, the article explains it very well.

sudo allows you to execute code as another user. If you think about it, you could also replace sudo with ssh to localhost - just set a root password and allow root logins. Now, security-wise, this would obviously be a bad idea. Our current solution is to give the sudo binary itself administrative privileges, which is a slightly less bad idea, but still pretty bad.

Systemd already handles logins, so it is quite obvious that it could also handle this problem very well, and in fact, it already does: there is a tool systemd-run which you can already use. It will create a completely new process and will handle communication to it, just like ssh, but without the above downsides.

constantcrying
6 replies
1d10h

Systemd already handles logins

Exactly that was my objection.

deng
5 replies
1d8h

And I disagree with that. The 'sudo problem' is a good example why it makes sense to handle init and login by the same system (note I'm not meaning "same binary" here, in fact, they are separate binaries in systemd). The SUID approach for sudo has been a problem for decades, and it needs to go. I don't really care if it's done by systemd, or if we agree on another system like S6 that was mentioned in another thread - in the end, they work very similarly be replacing the old sudo with an IPC approach.

cryptonector
4 replies
22h55m

I agree with u/constantcrying. This should not be part of systemd. It should be a separate service [started by systemd].

Reasons:

- systemd is a large beast -- no need to make it larger with unrelated things

- the Unix philosophy seems to be applicable here

- the result should be portable to non-systemd systems

deng
3 replies
9h44m

systemd is a large beast -- no need to make it larger with unrelated things

I think I sufficiently explained why it is very much related.

the Unix philosophy seems to be applicable here

Systemd very much follows the unix philosophy. It is not one big binary, but actually consists of dozens and dozens of tools communicating with each other through protocols.

the result should be portable to non-systemd systems

Portable on what basis? POSIX?

Spivak
1 replies
5h30m

People who just have an axe to grind with systemd really don't like when you point out that it's incredibly modular and follows the unix philosophy.

I think what people mean to say but don't have the words for is that systemd is an East coast school of thought project and folks prefer "worse is better" style tools.

cryptonector
0 replies
3h32m

I like the idea behind systemd. I don't have an axe to grind. I don't want SysV init or whatever you might think.

cryptonector
0 replies
3h28m

I think I sufficiently explained why it is very much related.

This:

| Systemd already handles logins

?

But I don't see why a bring-up/shutdown system should handle logins.

Systemd very much follows the unix philosophy. It is not one big binary, but actually consists of dozens and dozens of tools communicating with each other through protocols.

That is fine. As long as this service (sudo replacement) is a standalone, separate daemon started by a systemd unit, I'm happy. If it's a core part of systemd itself then I'm not happy.

Portable on what basis? POSIX?

Or Linux / glibc / musl, sure, why not. Some people (no, not me) want to run Linux w/o systemd. The point is that a sudo replacement service should be fairly portable to the universe of UNIX/Unix/BSD/Linux.

Starlevel004
7 replies
1d10h

But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none.

The systemd developers are tying it to systemd because they are systemd developers. If somebody else made something like this, it wouldn't be tied to systemd. But somebody else hasn't made something like this.

Sudo isn't going to just go away (unfortunately). You can keep using your CVE-ridden setuid binary as much as you want.

constantcrying
4 replies
1d10h

The systemd developers are tying it to systemd because they are systemd developers.

What? Literally every single other group of software developers has managed to create two projects. Even Microsoft can do it.

SAI_Peregrinus
3 replies
1d4h

GNU didn't. Why should Systemd?

gkbrk
2 replies
23h13m

You can use almost any GNU project without depending on all the other GNU projects.

SAI_Peregrinus
1 replies
21h10m

This is different from Systemd how? You can't use any GNU project without depending on GNU libc (except glibc itself, trivially).

enriquto
0 replies
11h55m

That is not true. I use gnu tools compiled with musl libc.

crashmat
0 replies
1d1h

noting I have been recommended doas as a more lightweight version of sudo so other people are trying to do this kind of thing

paulddraper
2 replies
22h54m

There is absolutely no reason to tie your new sudo replacement to systemd

It is said right there: the reason is to avoid the awkward SUID issues, and to have a privileged process create the process.

immibis
1 replies
19h42m

Instead you get awkward state management issues. Will the child really inherit everything it needs from the parent or has systemd forgotten to transmit something? If I chroot and then run0 will that process also run in the chroot? What about systems with older versions of systemd?

_flux
0 replies
9h27m

I imagine these questions are what might make this project non-trivial, but surely achievable.

If I chroot and then run0 will that process also run in the chroot?

That's an interesting question and it's not quite clear to me what should be the answer. For example, one legit answer might be that it would not work at all (in which case you would need to use some other tool that fits your needs), or another would be that the policy can decide what to do in that case.

But wouldn't you agree that it is better security hygiene to explicitly opt-in to inheriting properties when going to an elevated security level, instead of opting out from them?

hxelk1
1 replies
1d10h

I've spent a lot of time studying systemd alternatives. I believe the overall best design is Skarnet's s6, and that too includes a sudo-like program:

https://skarnet.org/software/s6/s6-sudo.html

I was very surprised when I learned about it, but it does make sense (for s6 at least).

There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none.

With s6, the idea is to replace a SUID binary with an IPC mechanism. That does make sense, since (parts of) the init system need to be running as root.

I am very glad to have jumped ship from systemd.

All that aside, so am I.

deng
0 replies
1d10h

With s6, the idea is to replace a SUID binary with an IPC mechanism. That does make sense, since (parts of) the init system need to be running as root.

Same idea with systemd-run.

Dalewyn
1 replies
22h58m

This is a completely insane way to develop software, instead of creating a new piece of software in a separate project

I appreciate and respect the KISS sentiment of doing one thing and doing it well, but oftentimes I also think open source programs' lack of integration with each other at a fundamental level is also one of its biggest downsides.

Being a Windows wizard unlike most folks around these parts, seeing and using the tight integrations between all the Windows subsystems is frankly marvelous and I wish Linux could have something like that.

tuna74
0 replies
21h20m

Linux is "just" an OS kernel. Integrations between user space programs have to be done by other people (like the systemd developers).

viraptor
0 replies
1d8h

It's not unexplainable. Any init by design is supposed to spawn new processes with the given environment, permissions, capabilities. When you run "your-init-cli start foo", you're starting a new service process. run0 is just one step away from that, because it connects the terminal to that process.

It's less "a new thing has been created with systemd" and more "a user interface was exposed for an existing functionality".

lugu
0 replies
1d10h

The article explains how this sudo replacement ties to systemd:

But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID.

I understand your frustration, but systemd isn't the first attempt to build an integrated system. It just happens to run on Linux. It isn't insane to develop software this way, from that perspective.

dcow
0 replies
1d10h

Why is this stupid? It’s just an option for how to configure a system that uses systemd to allow commands to be run in a privileged execution context without a suid binary. What’s wrong with having options?

Why don’t you propose a better solution? How would your non-systemd solution actually work?

Faaak
0 replies
1d10h

I find this quite clever. Yeah yeah, "systemd is bad, it's a monopoly, yadda yadda".

Well, there's also a reason they are doing it, and many aspects of it (seatd, timesyncd, resolved, run), and more neat than cobbling together bash scripts. I like it

airocker
72 replies
22h5m

I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.

mbreese
15 replies
20h35m

> across unix multiuser environments getting used anymore for servers

I guess it depends on the servers. I'm in academic/research computing and single-user systems are the anomaly. Part of it is having access to beefier systems for smaller slices of time, but most of it is being able to share data and collaboration between users.

If you're only used to cloud VMs that are setup for a single user or service, I guess your views would be different.

shrimp_emoji
14 replies
20h33m

If you're only used to cloud VMs that are setup for a single user or service, I guess your views would be different.

This is overwhelmingly the view for business and personal users. Settings like what you described are very rare nowadays.

No corporate IT department is timesharing users on a mainframe. It's just baremetal laptops or VMs on Windows with networked mountpoints.

mbreese
11 replies
19h59m

Multi-user clusters are still quite common in HPC. And I think you're not going to see a switch away from multi-user systems anytime soon. Single user systems like laptops might be a good use-case, but even the laptop I'm using now has different accounts for me and my wife (and it's a Mac).

When you have one OS that is used on devices from phones, to laptops, to servers, to HPC clusters, you're going to have this friction. Could Linux operate in a single-user mode? Of course. But does that really make sense for the other use-cases?

whimsicalism
6 replies
19h9m

is it? most HPC (if GPU clusters count) are probably in industry and managed by containers

bayindirh
3 replies
12h41m

HPC admin here.

Yes. First, we use user level container systems like apptainer/singularity, and these containers run under the user itself.

This is also same for non academic HPC systems.

From schedulers to accounting, everything is done at user level, and we have many, many users.

It won’t change anytime soon.

pankajkumar229
1 replies
9h59m

there is no reason for users to be maintained in the kernel.

bayindirh
0 replies
7h4m

Can you elaborate on that?

whimsicalism
0 replies
9m

I thought most containers shared the same user, ie. `dockremap` in the case of docker.

I understand academia has lots of different accounts.

birdiesanders
1 replies
15h43m

Containers rely on many privilege separation systems to do what they do, they are in fact a rather extreme case of multi-user systems, but they tend to present as “single” user environs to the container’s processes.

whimsicalism
0 replies
2h34m

they are in fact a rather extreme case of multi-user systems

Are they? My understanding was that by default, the `dockerd` (or whatever) is root and then all containers map to the same non-privileged user.

airocker
3 replies
19h40m

you could potentially create multiple containers in that machine which are single user and give to every user who needs access. CPU/Memory/GPU can be assigned in any way you want(shared/not shared). Now no user can mess up another user.

wongarsu
0 replies
10h54m

Isn't that just reinventing multiuser operating systems? Normal Linux already has the property that no user can mess up any other user (unless they are root or have sudo rights)

weebull
0 replies
10h30m

Not containers, but cgroups, and that is how HPC clusters work today. You still need multiple users though.

SoftTalker
0 replies
16h17m

It's not "that machine" it's a cluster of dozens or hundreds of machines that is partitioned in various ways and runs batch jobs submitted via a queuing system (probably slurm).

twic
0 replies
18h52m

I wonder if they might be more common than you think. You will never see someone standing up at a conference and describing this setup, but there are millions of machines out there quietly doing work which are run by people who do not speak at conferences.

Where i work, we have a lot of physical machines. The IT staff own the root account, and development teams get some sort of normal user accounts, with highly restricted sudo.

inopinatus
0 replies
12h6m

No corporate IT department is timesharing users on a mainframe

Not a mainframe perhaps, but this sentiment is flat wrong otherwise, because that is how Citrix and RDS (fka Terminal Server) do app virtualization. It's an approach in widespread use both for enterprise mobile/remote access, and for thin clients in point of sale or booth applications. What's more, a *nix as the underlying infrastructure is far from unusual.

I have first-hand insider knowledge of two financial institutions that prefer this delivery model to manage the attack surface in retail settings, and a supermarket chain that prefers it because employee theft is seen as a problem. It’s also a model that is easy to describe and pitch to corporate CIOs, which is undoubtedly a merit in the eyes of many project managers.

One of the above financial institutions actually does still have an entire department of users logged in to an S/390 rented from IBM. They’ve been trying to discontinue the mainframe for years. I’m told there are similar continuing circumstances in airline reservations and credit card schemes; not just transaction processing, but connected interactive user sessions.

This is what corporate IT actually looks like. It is super different to the tech environments and white-collar head offices many of us think are the universal exemplar.

rpgwaiter
11 replies
21h58m

NixOS may be helping multiuser make a comeback, at least it is for me and my home servers. I no longer have to containerize my apps, i can have one baremetal server with a dozen+ services, all with their own users and permissions, and i don't have to actually think about any of the separation.

Plus there’s network shares. Multiple people in my home with linux PCs, each with their own slice of the NFS pie based on user perms. Sure, it’s not secure, but these are people I live with, not state-sponsored hackers.

All that said, I’d also love a simpler single-user perm setup. For VMs, containers, etc it would be amazing

adastra22
5 replies
21h38m

I’m not sure how “I don’t have to actually think about any of the separation” meshes with the fact that you explicitly setup multiple users and configured file and group permissions accordingly. You clearly put a lot of thought into it.

Alternatively, containers really are a no-thinking-required solution. Everything maximally isolated by default.

airocker
2 replies
20h30m

There have been no big cves of container escapes for a while now. I guess it can be considered secure enough.

airocker
0 replies
1h35m

but then even traditional multi-user would be compromised in this case.

oceanplexian
0 replies
20h35m

Containers are isolated but a far, far cry from maximally isolated. They’re still sharing a Linux Kernel with some hand waving and cgroups. The network isolation and QoS side is half-baked even in the most mature implementations.

HVM hypervisors were doing stronger, safer, better isolation than Docker was 10 years ago. They are certainly no-thinking required though which leads to the abysmal state of containerized security and performance we have currently.

matrss
0 replies
3h52m

I’m not sure how “I don’t have to actually think about any of the separation” meshes with the fact that you explicitly setup multiple users and configured file and group permissions accordingly. You clearly put a lot of thought into it.

That's the thing, with NixOS you usually don't have to explicitly setup users and permissions. For most simple services, the entire setup is a single line of code in your NixOS configuration. E.g.

    services.uptime-kuma.enable = true;
will make sure that your system is running an uptime-kuma instance, with its own user and all.

Some more complex software might require more configuration, but most of the time user and group setup is not part of that.

inhumantsar
1 replies
19h28m

i can have one baremetal server with a dozen+ services, all with their own users and permissions

I've used nixos and I don't really see how nixos is special apart from the declarative config. The same can/should be done with any distro and any config manager.

And unless you were running Podman in rootless mode, the same setup applies to containers too.

rpgwaiter
0 replies
12h37m

Sure i could do this on debian, but like, i wont. Some software comes packaged with nice scripts to provision new users for running systemd services, but a lot do not.

For me and my home network, if the default security mode is “manage users yourself”, i chmod -R 777 on all applicable files and call it a day. Nixos lets me be lazy, as all nixos modules (that I’ve ever used) have their own user setups with minimal permissions by default

tetris11
0 replies
21h25m

DietPi does exactly the same using Debian

eru
0 replies
12h38m

Containerisation (either with containers or via VMs) doesn't have to be expensive.

In principle, you can have just exactly the binary (or binaries) you need in the container or VM, without having a full Linux install.

See eg Unikernels like Mirage.

airocker
0 replies
21h56m

NixOS at it again :)

mbivert
10 replies
21h32m

I've never understood the need for sudo(1) on single-user, physical machines: I keep a root shell (su(1)) around for admin tasks, and it's always been sufficient.

lupusreal
5 replies
20h6m

One password is easier than two and it feels weird to use the same password for both accounts. About half of my sudo invocations are 'sudo su' lmao.

bmicraft
1 replies
18h58m

You could probably save a process with `sudo -i`

lupusreal
0 replies
4h45m

Slightly less convienent to type.

mbivert
0 replies
11h53m

it feels weird to use the same password for both accounts

I'm not sure different passwords adds more protection for single-user machines, especially when sudo(1) can spawn root shells!

lanstin
0 replies
14h32m

of mine are sudo bash.

MadnessASAP
0 replies
16h12m

You're entering your own accounts password, not root, when you use sudo. It's a security measure to prove our shell hasn't been hijacked and to make you pause and acknowledge your running a command that may affect the entire system.

You can also disable it in the sudoers file.

chgs
1 replies
19h57m

Everything I run with sudo is logged so I know how I messed up.

Nothing worse than ansible with its “sudo /tmp/whatever.sh” which hides what it’s doing.

mbivert
0 replies
11h38m

Everything I run with sudo is logged so I know how I messed up.

FWIW, shells have a (configurable) history file. I'm not sure how it compares to sudo's logging though. I also personally perform little day to day admin tasks (I don't have as much time nor interest to toy around as I used to, and my current setup has been sufficient for about a decade).

Nothing worse than ansible with its “sudo /tmp/whatever.sh” which hides what it’s doing.

That's a nightmare indeed; for sensitive and complex-enough tasks requiring a script, those scripts should at least be equipped with something as crude as a ``log() { printf ... | tail $logfile`` }.

airocker
1 replies
21h11m

Its just maybe easier way to not have to go to the root shell.

mbivert
0 replies
20h54m

Makes sense (I keep one warm in a tmux, two shortcuts away at most, so it never occurred to me).

berkes
5 replies
20h42m

I always still split up "sysadmin" from "deploy".

Ephemeral setups (amongst which k8s) remove that need but introduce a big load of other stuff.

Having a VPS that is managed by sysadmins (users with sudo rights, authed with keys) and on which partly overlapping "deploy" users can write to small parts and maybe do a passwordless "sudo sysctl restart fooapp" but only that, is a nice and simple setup.

I manage at least seven of these. And nothing in me even considers porting this to my k8s infra.

Edit: The reason for this setup is simple and twofold: deploy is safe and clear: deployers can be confident that whatever crap they pull, the server will churn on, data will be safe, recovery is possible. And all devs/ops having their own keys and accts gives a trail, logs and makes it very easy to remove that contractor after she did her work.

theteapot
3 replies
19h34m

I think you mean systemctl.

8372049
2 replies
17h49m

He probably meant sysadmin as in the account with sudo access.

BenjiWiebe
1 replies
14h30m

s/sysctl/systemctl/

berkes
0 replies
11h35m

Correct. Typed it on mobile.

eru
0 replies
12h40m

Yes, we are moving more and more towards a system of immutable deployments.

That's good! We don't patch executable binaries these days: we just compile a new one from source, when we made a change. Similarly, more and more we just build new systems (or their images) from source, instead of mucking around with existing systems.

NewJazz
4 replies
19h37m

You only have one admin? How do you know who logged in, ssh certificates?

airocker
2 replies
19h19m

Only one human per machine. If you need to share the machine, make multiple containers and give everyone a separate container.

NewJazz
1 replies
18h22m

You don't run any services where more than one person shares responsibility for managing that service? E.g. kubernetes. That is just one guy holding it up?

airocker
0 replies
17h40m

In an on-prem cluster, yes one guy or a few sysadmins who either share passwords or can somehow put their keys in the authorized keys file and ssh.

In the cloud, AWS/GCP let or not let an IAM user reach a server.

medellin
0 replies
19h18m

Signed ssh certs make your life easy here

jongjong
2 replies
17h20m

Technically not with virtual machines as the hardware is shared, though I agree, nowadays accounts and access control of the system belong to the virtualization layer below. The benefits of multiple accounts per machine are tiny and not worth the complexity for server setups.

We could significantly simplify things by getting rid of the account system. The same could be said for a lot of systems like database servers. Typically it's just one database, one user (your application server) with full access. The account system is mostly an annoyance.

For big company use cases where you want to reduce attack surface, why not spawn a second server with different credentials? Anyway big companies typically have many database servers in a cluster and the same credentials are shared by many server processes... The tendency there is literally in the opposite direction.

zer00eyz
1 replies
15h4m

> Typically it's just one database, one user (your application server) with full access

This is a terrifying way to access databases.

Super user, A Modify user (just below super but cant delegate rights) for schema changes. A read/write app user... Probably a pile of read only users who, have audit trails... You might want some admins or analytics users (who have their own scheme additions).

The words security and audit trails all spring to mind.

jongjong
0 replies
3h48m

A simpler solution is to simply not give direct access to the database to anyone who doesn't own a large stake in the project. Expose it via a more restrictive CRUD interface with access control in the application layer.

hobobaggins
2 replies
1h51m

We use Userify which manages multiple user logins (via SSH) and sudo usage.. there are definitely many, many use cases for teams logging into remote servers, and most security frameworks (PCI-DSS, HIPAA, NIST, ISO 27000) require separate credentials for separate humans. Sudo has some issues, but it works very well and is well understood by many different tools.

airocker
1 replies
1h19m

It could all be simplified and map one to one to your identity provider credentials at a higher level. Having a complicated user system on the servers makes it a problem.

trueismywork
1 replies
19h32m

You'll just end up implementing multiuser support anyway due to different permissions to different devices services

airocker
0 replies
19h26m

How about only in servers where you only have CPU/Memory/disk/GPU with open source trusted drivers?

imtringued
1 replies
9h4m

You run everything as root or how am I supposed to understand that?

Sudo exists to execute commands with a different user. It's an abbreviation of "switch user (then) do" for a reason.

Most daemons run under a specific user. Things like docker that use a root Daemon are a security nightmare.

gnufx
1 replies
21h47m

Visit the research computing environment sometime, for instance. The libzma SSH compromise was considered very worrying, after all.

richardwhiuk
0 replies
21h16m

That didn't need multi-users.

blablabla123
1 replies
4h51m

Yeah but elevated permissions may be needed from time to time anyway. Either on the client, the baremetal server or the container. Running everything as root is even for containers not recommended. Considering how popular these have become, it's a bit of an irony that systemd isn't available on the container without considerable detours.

airocker
0 replies
1h27m

One user with sudo for sysadmins on baremetal and a sudo access without CAP_SYSADMIN on container should be good.

badgersnake
1 replies
11h43m

I haven’t seen it doesn’t mean it doesn’t exist.

airocker
0 replies
1h28m

Exist does not mean it should keep existing if it is unnecessary complexity from the past.

anonymous_union
1 replies
20h57m

in some other systems the concept has become overloaded. instead of multiple real people as users, different software with different permissions are different users. its not a bad abstraction.

airocker
0 replies
20h51m

Maybe containers are a better way of isolating processes as mentioned in other comments.

TZubiri
1 replies
21h47m

access management is usually delegated to other systems that supervise UNIX, like AWS

airocker
0 replies
21h46m

Or Kubernetes. Thats where a standard way of authentication/authorization should be there.

unixhero
0 replies
13h32m

The humans are now spawns of multithread shells and other things. Linux land is still very multiuser oriented. But it is the rise of the mschines instead.

bayindirh
0 replies
12h45m

Many, many daemons run under their own users. Just because a single human is using the system, it doesn’t mean the system has a single user.

Also, people noted HPC, and other still very relevant scenarios.

fn-mote
52 replies
1d2h

Overall, this seems great.

However...

[...] by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges

?!! ouch ... seems orthogonal to the actual important parts.

Disclaimer: I didn't try it.

NekkoDroid
27 replies
1d2h

I tried it a bit ago (when it was still called uid0, pre-release), I also wasn't a fan of the tinting.

I like the intent behind it, but some terminals already tint the header color when running sudo, I haven't tested if its done specifically for sudo or if its in a more generic way that could handle this as well.

Karellen
14 replies
1d1h

I also wasn't a fan of the tinting.

From the linked mastodon thread:

For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven't given up the privileges yet, and marks the output of all commands that ran with privileges appropriately. (If you don't like this, you can easily turn it off via the --background= switch).

(emphasis mine)

gh02t
4 replies
22h10m

It was a bit unclear to me from the thread, is there a persistent configuration option for this? I like the idea of tinting the terminal, but I also want to be able to turn it off with a global config option rather than having to type out a --background flag every invocation.

zamadatix
3 replies
22h6m

Aliasing the command as the command + your default arguments is the easiest general solution to this kind of problem. I'm not sure if there is a "systemd way" to permanently set it though.

tolciho
1 replies
19h32m

I accidentally compile color support out of st, or set xterm*colorMode:false to avoid seeing the backside of a unicorn randomly rubbed all over the terminal, on account of git and other wares being bad at their inability to not spew color codes. A sensible default would be to set no colors, in the event that the colors are unreadable (due to colorblindness, etc) or distracting, but that ship sailed. Most of my vim config on RedHat linux was disabling wacky vendorisms, and back when I used linux I did have a "special terminal" for some NVIDIA installer that mandated colors to be usable. Maybe the terminal title was set to Fisher-Price, maybe not.

shrimp_emoji
0 replies
5h10m

Dang. I wish I had the autism to bristle at colors. Think about all the lost hours agonizing over themes! Not feeling the agonizing tension between the fact that cool-retro-term made your terminal into an awesome monochrome CRT but that it's monochrome green so your syntax highlighting is all messed up!

back when I used linux

What do you use now? :0 BSD? Plan 9???

gh02t
0 replies
21h50m

True, I was thinking a simple environment variable or systemd configurable would be fine but I guess an alias is a good idea.

deadbunny
4 replies
20h10m

I for one love to type out 13 extra characters to a 4 character command to disable dumb choices by the developer.

On a more serious note, I wonder what random ASCII escape sequences we can send.

BenjiWiebe
2 replies
14h26m

'alias' is your friend.

deadbunny
1 replies
6h0m

I shouldn't need to alias behaviour that violates the principle of least surprise on every single machine I need to run elevated commands on.

shrimp_emoji
0 replies
5h15m

Eh.

`alias grep='grep --color=auto'`

`alias ls='ls --color=auto'`

It's canon.

Karellen
0 replies
8h10m

I for one love to type out 13 extra characters

FWIW, systemd is normally pretty good at providing autocomplete suggestions, so even if you don't want to set up an alias you'll probably just have to type `--b<TAB> ` to set it.

I wonder what random ASCII escape sequences we can send.

According to the man page source[0]:

The color specified should be an ANSI X3.64 SGR background color, i.e. strings such as `40`, `41`, …, `47`, `48;2;…`, `48;5;…`

and a link to the relevant Wikipedia page[1]. Given systemd's generally decent track record wrt defects and security issues, and the simplicity of valid colour values, I expect there's a fairly robust parameter verifier in there.

In fact, given the focus on starting the elevated command in a highly controlled environment, I'd expect the colour codes to be output to the originating terminal, not forwarded to the secure pty. That way, the only thing malformed escapes can affect is your own process, which you already have full control over anyway.

(Happy to be shown if that's a mistaken expectation though.)

[0] https://github.com/systemd/systemd/blob/main/man/run0.xml

[1] https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_G...

zamadatix
3 replies
22h8m

I think it's more that the default seems backwards than the lack of ability to change it.

dsr_
2 replies
21h46m

It's three things:

* here is a feature which we are defaulting to on

* there's no persistent config for it

* we know better than you do about your preferences

zamadatix
1 replies
20h23m

"Defaulting to on" is just a symlink to an existing binary so that's not really much a problem.

gpm
0 replies
17h49m

A symlink to a binary that I'm going to pass a password to seems like a security bug waiting to happen (just in the manner that any complexity around privilege escalation is a bad idea).

withinboredom
11 replies
1d1h

I can think of a number of things this tinting would break.

seanc
5 replies
21h3m

It violates the principle of Least Surprise; if I'm invoking run0 I'm expecting it to run my program with a different UID and return the same stdout I'd have gotten if I had just run the program in my shell. Not inject a whole bunch of color control bytes in there. Which hopefully my terminal will handle. Unless it doesn't.

I'll give them the benefit of the doubt and assume they only do this if $TERM supports color. But still. That $TERM variable can surprise a poor programmer in all sorts of ways.

zeroimpl
2 replies
18h36m

But sudo already doesn’t do that either. Eg sudo may ask for a password, and output some control sequences which hide the text so your password is not visible.

This feels like much ado about nothing.

Edit: Also don’t forget the “with great power comes great responsibility” blurb that sudo likes to output. I know that doesn’t happen in scripts when output is redirected, but I’m sure run0 will figure that out too.

withinboredom
0 replies
12h4m

sudo may ask for a password, and output some control sequences which hide the text so your password is not visible.

You can turn this off for certain users and/or programs.

dijit
0 replies
18h0m

asking for a password to do an authenticated action is about as far away from surprising as I can legitimately reason about.

The contextual blurb does have a way of disabling it in a persistent config, which is easy enough to set. It also goes to stderr and not stdout and does nothing to alter the output of the command itself.

It also does not show if you have NOPASSWD: set in your sudoers. So even less surprising.

10000truths
1 replies
19h23m

Any sane command line program will only output color codes if isatty(STDOUT_FILENO) succeeds.

withinboredom
0 replies
19h15m

That can succeed in a number of cases, where it actually isn't a tty with a user on the other end of it. There are a number of internal tools at work that only output logging if there is a tty and thus are run in their cronjobs with a tty. If there were unexpected color outputs in the logs, that would suck since the log aggregators probably wouldn't know what to do with it.

lupire
4 replies
1d

Can you name any?

withinboredom
0 replies
19h9m

Containers run with a tty attached but no console on the other end and then trying to read the logs, for starters. Additionally, as mentioned, conflicts with the user's color scheme or even the program's. Further, it's possible to do this without the help of run0, so I suspect users already doing that are going to get their colors messed up and be annoyed. For example, prod machines are usually red, and running as root on a prod machine is royal purple. If this is used, seeing a red background instead of a purple one is likely non-desirable.

snvzz
0 replies
6h44m

XMODEM and the like expect the terminal stream to not have garbage added by e.g. run0.

The terminal line should be clean between XMODEM at the terminal emulator and at the client end.

shiomiru
0 replies
19h52m

If the program you're running prints red text, then you get red bgcolor with red fgcolor. Good luck reading that.

(Also, users with the wrong color scheme get that experience by default. Though that is a niche use case enough that I'd be surprised if systemd devs cared about it.)

dsr_
0 replies
21h48m

The user's choice of color schemes.

bityard
21 replies
22h18m

This is a perfect example of a choice that a developer makes to suit his/her personal preference and environment, believing that everyone does (or should) use their computer the same way. Which is sadly becoming a more common trend.

I like the idea, but I don't think it should be on by default. The rest of us have just used root-specific shell prompts for the last few decades or so.

TZubiri
20 replies
21h46m

It's fine.

Not every software needs to be infinitely configurable and open source just in case the configurations don't cover the needs of all.

We need opinionated software, if you don't want to make any choice for me, you can't even give me an assembly editor for fear of forcing your CPU arch of choice.

shrimp_emoji
14 replies
19h48m

Counterpoint: GNOME and the modern GTK framework

(I needn't say more.)

yoyohello13
10 replies
19h29m

Gnome is great if you're willing to do things their way. I Like Gnome a lot actually.

flaptrap
9 replies
18h40m

Gnome's UI peaked at 2.32. Find out how the users operate and implement so users can work efficiently. Don't make changes just to make your mark or to make users work on the desktop like they see on a cell phone. That is so basic.

MadnessASAP
5 replies
16h9m

I have no idea why Gnome keeps on insisting on breaking expectations. From the shell as a whole to the widgets and even the window titlebars they seem to insist on being different for the sake of being different.

abenga
4 replies
13h57m

Because their choices are better, at least for some of us. Users who prefer the traditional desktop paradigm have a wealth of alternative DEs to choose from.

MadnessASAP
3 replies
13h47m

I suppose my brutally minimalist Sway config with barely there titlebars and a skinny little status bar and not an icon, button, or widget in sight doesn't give me great standing to call for a respect of conventions.

I suppose I should say I found Gnomes luridly chunky decorations and widgets to be personally offensive.

abenga
2 replies
12h28m

What widgets? Gnome has just the one black bar at the top.

MadnessASAP
1 replies
11h59m

And it's a thick monster with all kinds of extra crap (I'm my not so humble opinion) shoved in it.

abenga
0 replies
9h55m

It literally has an activities button, the time and date, and a tiny button for interacting with settings on the right.

loeg
0 replies
15h19m

These days KDE gets a lot of the same things right that GNOME 2 did.

jimbosis
0 replies
15h56m

I don't know if you are DE shopping, but I've been very happy for the past few years with the MATE Desktop Environment, which "...is the continuation of GNOME 2. It provides an intuitive and attractive desktop environment using traditional metaphors for Linux and other Unix-like operating systems."

https://mate-desktop.org/

Among a great number of things I really like, I will mention that Caja, the MATE version of GNOME 2's Nautilus file manager, can still be switched to spatial mode.

https://en.wikipedia.org/wiki/Spatial_file_manager

Generally speaking, I too really liked GNOME 2.32 and its predecessors, and, as far as I'm concerned, MATE is as it describes itself.

EDIT: Wording mistake.

abenga
0 replies
14h0m

Gnome is always getting better (if you want to do things the Gnome way). Why should a DE show any elements begging to be clicked on my desktop while I am working (window list, etc)? I am only interested in what's in my IDE, terminal, and browser. Present Gnome comes closest to my ideal of fading into the background and letting me focus on my tasks.

metalspoon
1 replies
17h57m

Yes. I prefer having tools that do one thing well. That's the point of unix. How the user uses them should be up to her.

GNOME offering a monolithic environment with heavy opinionation is the opposite.

flexagoon
0 replies
3h59m

How is GNOME a "monolithic environment"? The entire GNOME ecosystem is basically small apps that do a single thing well:

https://apps.gnome.org/

johnny22
0 replies
18h6m

actually you do, because gnome is great

aragilar
3 replies
10h30m

You can't think of ways this could break things? I would find this a useful feature, but I'm also aware of how this works, and the issues it could cause.

Spivak
1 replies
5h50m

No? Of all the esoteric escape sequences that terminals handle the ones that change colors are well trodden.

aragilar
0 replies
4h50m

There are at least 3 different ways of expressing colour as covered by https://en.wikipedia.org/wiki/ANSI_escape_code#Colors, and given the wide propensity of newer terminals to misidentify what they are (I know I have some additional checking in my shell startup to unbreak things if needed), and/or bad termcap/terminfo settings on older systems, sending terminal sequences that are apparently supported but are not happens surprisingly often (enough such that I've made sure to always install two different terminals which use different rendering backends, e.g. xterm and VTE).

acdha
0 replies
1h43m

It could, but this is a non-default tool focused on new use so the first question I’d ask is how many of the people using it are running the weird edge-case terminals where that’d break something. I wouldn’t want to end up in a Microsoft-style trap where nothing can improve because someone somewhere depends on strict fidelity with 1993.

bityard
0 replies
24m

I don't understand the part about the assembly editor, but I'm not sure I agree with the rest.

Whenever I hear someone describe their software as "opinionated," I have found what that usually means is that the developer thinks they are smarter than everyone else and all of the unfriendly attitude that usually comes along with that.

Whoever made the decision that run0 should turn your terminal red by default doesn't understand that there are practically infinite terminal configurations out there that this will interfere with or be outright incompatible with. My argument is that the decision comes from a place of ignorance of the sheer diversity of the users of the software, not from a place of, "we are so smart, and are the first ones to think of this feature."

whalesalad
0 replies
15h30m

This is a thing in certain environments. I don’t mind it.

sfink
0 replies
1h52m

Yeah, that's the part that stuck out for me. "sudo is bad because it does all these things it shouldn't do instead of just the one thing it's for and nothing else. My tool is good because it does just the one thing it's for — plus this other random thing because I think it's cool."

pmlnr
35 replies
1d12h

The developer talks about the weaknesses of sudo, and how it has a large possible attack surface

Poettering's hypocrisy is painful.

mort96
34 replies
1d11h

Is it? Does systemd's sudo replacement also have a lot of complex code running as root in a suid binary?

Because that's what he's complaining about

jpollock
28 replies
1d11h

People blame systemd for making the liblzma problem larger than it should have been.

https://marc.info/?l=openbsd-misc&m=171227941117852&w=2

"Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency."

https://news.ycombinator.com/item?id=39866076

"openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma."

deng
23 replies
1d11h

So that's your best shot against systemd?

- Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library.

- libsystemd depends on libzlma

- libzlma depends on xz

And therefore, systemd is insecure?

And what does this have to do with the fact that SUID is a terrible idea that needs to go?

James_K
9 replies
1d10h

- libsystemd depends on libzlma

- libzlma depends on xz

And therefore, systemd is insecure?

Yes. You have literally just described the way it is insecure. It bundles a large amount of functionality under a single system, and therefore anything using that functionality is at risk. You seem to be suggesting that Systemd would be secure if you didn't use it, which is obviously fallacious. Anything is secure if you don't use it. Systemd offers this functionality, and did it in an insecure way. You cannot blame users for that. Saying that people shouldn't be using a certain part of Systemd is really the same as saying that part shouldn't exist to begin with. The conclusion is obviously that Systemd should be smaller to decrease the chances of things like this happening.

Xylakant
8 replies
1d6h

LZMA is a widely used compression protocol. The kernel uses it. xz - the compression tool that was affected gets used by the kernel build makefiles - they reference it in the build docs https://docs.kernel.org/staging/xz.html. It's absolutely fair from systemd to have this dependency and to use the trusted library that the most fundamental part of the underlying OS uses.

It was purely the attackers choice to leverage the exploit via systemd instead of injecting code in the kernel at build time.

James_K
7 replies
1d4h

Your speculation on what is right and what was fair is of no consequence to me. Their error was not simply using a compression library, it was creating a large central point of failure. If Systemd was smaller, it would not have caused this error. By being large, it made itself vulnerable. It made itself a target. It made other software insecure. These facts are inescapable. And you cannot justify this by simply saying they didn't do anything wrong right before the attack, or that packagers are to blame, or that other software might also be vulnerable, or anything else that doesn't address the core of the issue: Systemd created the circumstances needed for this to happen. They were warned of he risks they created, and chose to do so anyway. Now those risks have been made manifest – the inevitable result of a fundamentally flawed design.

growse
6 replies
1d3h

Why is this an argument specifically against systemd, rather than all large software projects?

Linux kernel, gcc, glibc - all bundle "a large amount of functionality under a single system" - does this make their design fundamentally flawed as well?

James_K
5 replies
1d1h

I think a micro-kernel architecture would be better in many ways, security being just one of them. With GCC, it couldn't really be separated into logically distinct modules any more than it already is. All of the constituent parts essentially use the full functionality of the base compiler part, so there is little to be gained separating them. It's not as if the C compiler from GCC, could for instance, be written in such a way that it doesn't depend on GCC. GLibc is a large implementation, but the library itself doesn't necessarily need to be large. There are some very small libcs out there.

On the whole, I do not like monolithic software projects, but I can accept that they are necessary or beneficial in some cases. Systemd is simply a much bigger target than these other things because it is an especially bad example. It has many components which are only tentatively connected. It is also more fixable. Alternate init systems are used much more widely than something like Hurd to replace Linux. The laptop I'm typing this from runs GuixSD which ships without Systemd and I can hardly notice the difference. I doubt a different kernel architecture would provide such a seamless experience.

Xylakant
4 replies
1d

Given how common LZMA as a compression algorithm is, are you certain that your init system of choice doesn’t use it in any way? It’s a very common algorithm in network protocols, it’s a direct dependency of libxml, … - and if any part of your init system uses LZMA, then it just happens not to be affected because the attacker chose to target one specific system.

James_K
3 replies
21h34m

I wouldn't be affected regardless, because SSH doesn't depend on my init system.

Xylakant
2 replies
21h10m

The attacker had essentially full control over a very fundamental library in the Linux ecosystem. They could have leveraged that in a hundred ways.

The attacker chose to target a very specific component of a very specific system. It was their choice, not some sort of technical requirement that made it impossible to use a different attack vector. Just as they chose not to target other Linux distributions that use systemd.

You’re essentially saying “I was safe because the attacker chose to ignore me.” That worked well this time, but it’s a pretty dangerous stance.

James_K
1 replies
9h14m

When a hacker chooses to attack something, that isn't random. They had to look at a lot of different pieces of software, and decide which would be the best to attack. The choice in this case was Systemd. In other words, if you are looking to do malicious things, Systemd is helpful.

Now I want you to imagine that every piece of software has a score, which tells you how useful it is to hackers. Systemd has a high score, and hence it was chosen for this attack. Your argument is that: there are other pieces of software with a high score so it's fine for Systemd to also have one, since without it there would be other things to attack. My argument is that we should reduce the amount of software that has a high score. Do you think my reasoning or your reasoning will lead to a more secure ecosystem?

growse
0 replies
45m

The size of libsystemd is immaterial in the case of xz. The attackers had control of xz, and wanted to load it from sshd.

There's lots of projects that link xz, big and small. Patching sshd to include any of them would have implemented the backdoor.

tgv
8 replies
1d11h

First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS.

Second, when even the package maintainers can make such "trivial" mistakes, something is wrong. You'd expect a component such as systemd to be much more trustworthy than some random library.

I'm not arguing against systemd, just that it seems to grow and grow, and is not the correct place for security. It security is obviously broken.

mike_hearn
3 replies
1d7h

If it was "obviously" broken why was the xz backdoor such a shock to everyone? Do you personally audit the library dependencies of every tool you run, including core servers that come with your distribution? I think people don't do this.

Also, even before the backdoor was discovered, the systemd team were making libxz be dynamically loaded only in the cases where it was needed which would have killed the backdoor dead. There's some evidence that this might have actually caused the backdoor to be sped up and hence led to its discovery. Claims that systemd has bad security have to explain why it was already implementing practices that would have blocked the xz backdoor without it even being discovered. That seems pretty decent to me.

tgv
2 replies
1d3h

The point is that (even) the systemd maintainers do not vet their dependencies. As an attack vector, it is the (second?) highest level, yet they did not assume the responsibility. Everybody silently assumed they did, hence the shock.

Claims that systemd has bad security have to explain why it was already implementing practices ...

No, they don't. It doesn't take away the fact that they did not check xz, and probably only few of their other dependencies.

mike_hearn
1 replies
1d2h

Nobody was silently assuming the systemd maintainers were reviewing the source tarballs of every dependency for obfuscated back doors.

tgv
0 replies
4h12m

That would be irresponsible and strengthen the case against run0 as a replacement. And let's be honest this time: the argumentation is that it's there to replace sudo.

deng
2 replies
1d10h

First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS.

It absolutely is. sudo allows you to execute code as another user. If you want to do that without giving sudo itself administrative privileges, this has to be done through the service manager, which creates a completely new, elevated process and handles communication with that. This is how it should be done (and BTW, this is pretty much how also the new sudo for Windows works). Now Lennart for some reason prefers systemd as this service manager - you might disagree with that choice, but then come up with a better one.

tgv
1 replies
1d8h

Decoupling/single-reponsibility is sort of lesson #1 in software engineering.

then come up with a better one.

Really?

deng
0 replies
9h53m

Decoupling/single-reponsibility is sort of lesson #1 in software engineering.

Well said. What makes you think systemd does not do this? Have you ever even looked at systemd in any amount of detail? Do you think it is one big binary running as PID1 doing everything?

jononor
0 replies
1d10h

Package maintainers of a distro can do absolutely anything to a package. With zero input from upstream developers. Some distros have more tradition for patching software than others. An upstream like systemd (or openssh) can hardly be blamed for what others do with their software.

lmm
3 replies
1d11h

- Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library.

Why was that? Would that "trivial" approach have broken the next time systemd made one of their incompatible interface changes, perhaps? Was using libsystemd the kind of thing the systemd maintainers recommended?

And therefore, systemd is insecure?

Systems with systemd had a vulnerability that systems without systemd did not. So it certainly seems like systemd-the-system (not necessarily systemd-the-unix-process) is bad for security.

Xylakant
1 replies
1d10h

You're not making a very good point here. A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2. LZMA is a pretty widely used compression algorithm, I'm absolutely certain there's other juicy targets that depend on liblzma.

The reason why "only" sshd on debian/ubuntu was affected is that the attacker chose to tailor their exploit to those systems. Systemd was the vehicle, debian patching opensshd was what made this specific incarnation of the attack possible, but essentially, both trusted a widely used library.

lmm
0 replies
20h17m

A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2.

Sure. But security-critical software like SSH would certainly think twice before bringing in such a huge and complex dependency as an XML parser.

I'm absolutely certain there's other juicy targets that depend on liblzma.

You could probably make a system package manager (which has obvious reasons to depend on a compression algorithm) do something nefarious. But that would be a more complex chain of exploitation with more chance for things to go wrong. Most security teams put more attention on security-critical parts like SSH, and I think most people would agree they're right to do so.

mort96
0 replies
1d7h

My understanding is that the UNIX socket based protocol which libsystemd wraps for this specific feature is documented, stable and simple.

mort96
3 replies
1d10h

What relevance does this have? Poettering's complaint is that sudo is way too big for a SUID binary, sshd is not a SUID binary?

And neither Poettering nor the systemd developers patched said, the Debian people did that. Seems weird to blame systemd for that?

jpollock
2 replies
1d1h

The complaint is that the code architecture of systemd results in security problems for their _customers_.

The inclusion of a library to send notifications shouldn't have external dependencies, it shouldn't need them. The library is included in the customer's codebase at execution time, so it is a hole in the customer's security model. This immediately opens a supply chain attack vector (which is what we saw).

This is being taken as evidence that they shouldn't have responsibility for truly security sensitive code - the replacement of sudo.

Some of this is a long-term dislike for systemd and some representative bias. However, Systemd has missed the opportunity to make their client libraries safer.

Personally? I wouldn't have thought to limit the dependencies of my client libraries. It's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently.

Using systemd as intended shouldn't result in security holes for their customers.

mort96
1 replies
8h16m

"Systemd is bad because Debian patched OpenSSL to add an unnecessary dependency on a systemd library" is just not a good argument, sorry. Nothing about the "code architecture" of systemd caused the xz issue.

And again, Poettering's complaint with sudo is specifically about it being a SUID binary, so this discussion isn't even related to the thing you're accusing them to be hypocritical about... SUID is more than just "code running as root", it's "code running as root in an attacker-controlled environment". That last part is the important one.

jpollock
0 replies
55m

By "code architecture" I mean the packaging of their client libraries.

This attack demonstrates that they should be tightly focused and have minimal downstream dependencies.

I don't have any experience with systemd, but typically, people will bundle _all_ of their client libraries into one .so and say "use that".

However, what needs to happen is there should be multiple .so's, one for each sub-API. At least there should be libraries for frequently used shim code (like notifications seems to be).

Then systems that need to push information don't need to pull in the dependencies for other parts of the overall systemd interface.

I can't think of a reason why pushing local notifications would require a compression library. The notifications should be information heavy already, so not very compressible.

As I said, it's a growth and project age thing. One moment you're on one side of a line, the next you have to skill up and do things differently.

How the team responds is what is important. That is why people are objecting to the SUID work. Not because sudo isn't a hole, but that the systemd team isn't considered responsive enough to take it on.

I know I'm taking lessons from this to my work. It's an unpleasant mirror for me to look in.

pmlnr
2 replies
1d9h

The complaint might be valid. The solution, to shoehorn yet another functionality on systemd will in no way reduce complexity or attack vectors, merely shift them, again, like with all systemd solutions.

mort96
0 replies
8h9m

What difference does it make if it's part of the systemd project or not? Do things suddenly become a more problematic attack vector when they're organizationally part of the systemd project instead of the sudo project?

kreetx
0 replies
1d5h

The systemd attack vector is already there, and now the SUID attack vector is removed - sounds like reduction in attack vectors, no?

mid-kid
1 replies
1d9h

systemd has a lot of complex code running as root (that can be reached without privileges more often than not) and has had its fair share of CVEs.

The hypocrisy is in calling out a different project for being an overengineered tool running with too high privileges.

mort96
0 replies
21h54m

It's not just about running as root though, but as being in a SUID binary.

jimrandomh
33 replies
11h13m

Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).

I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have a normal shell command, making use of the environment for context in all the ways that shell commands do, but it doesn't have all the permissions it needs, so you add "sudo" as an adverb.

Sometimes it makes use of environment variables. Sometimes stdin or stdout is redirected to a file, or to something more exotic than a file. Sometimes that means it runs inside of a chroot, or a Docker container. Sometimes you care about which process group it runs in.

And sometimes the thing you're running is a complicated shell script or shell-script-like object, eg "sudo make install". In this case, you don't really know what its dependencies are. In fact this is a common enough case that, if run0 becomes widespread, I expect it'll have a flag or a set of flags that make it act exactly like sudo, and I expect people to wind up learning that they should always give run0 those flags.

And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.

lyu07282
13 replies
10h11m

I think what is perhaps something to consider is how much of an attack surface sudo is and how unaware people are of the fact. Many people think they can configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it. But they don't realize all the ways it can be abused for privilege escalation. Getting rid of all that configuration removes that false sense of security, which is a good thing, it has been a huge footgun in Linux for decades. Some incompatibility is price well worth paying for that imho

lupusreal
12 replies
9h11m

I think these problems are basically negligible because the amount of people trying to "configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it" is negligible. Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of. Even in corporate contexts where the company owns the machine instead of the user, I've only ever seen cases where the use of sudo is unrestricted albeit logged. Where are these organizations where developers or syaadmins are allowed to use sudo but only with white listed commands? I don't doubt that some people are doing this, I just think it's not common.

Replacing the whole of sudo with some weird new thing to better support a niche usecase seems disconnected from reality to me.

sapphire_tomb
6 replies
8h56m

My last job was at a UK bank. All our *nix systems were configured with a specific whitelist of commands that could be run via sudo. We found this an enormous pain in the arse when the powers that be decided to deploy ansible everywhere, and found that none of its "become" methods would work if sudo was set up like that.

fullstop
3 replies
4h26m

I had a job once which had a sudo whitelist, but vi was included. !sh and you had root.

TheRealDunkirk
1 replies
3h36m

Classic case of #CorporateIT applying white paper "rules" and not understanding what they're doing. If I had a nickel...

fullstop
0 replies
59m

Exactly, forms were filled in and boxes were checked off.

acdha
0 replies
1h39m

I also liked one where you could `sudo rpm -i`

jeremyjh
0 replies
8h2m

Those environments could continue to use sudo. I'm sure Red Hat will support it until long after we all dead.

WesolyKubeczek
0 replies
8h26m

Not even using "su" as become_method? Granted, it would require the root's password, so it's another tradeoff, but...

Hendrikto
2 replies
7h23m

Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of.

This is not the case at all. The vast vast majority of Linux installs are on servers.

troyvit
0 replies
5h15m

Then I propose letting systemd hijack sudo's usefulness only on server installs.

tomxor
0 replies
4h38m

That's not what parent means. They are arguing it's not generally used to delegate partial root access to unprivileged users, i.e by adding narrow sudoers rules to allow "some" specific things to be run as root for some users who don't have full root access otherwise.

I tend to agree that 99% or use cases are just a convenient way to gain full root for users with full root access. Configuring sudoers for the former use case has long known to be a bit dangerous, i.e it's easy to get it wrong and create privilege escalation holes.

lyu07282
0 replies
5h20m

Its a common finding during pentests, but that's just unconvincing anecdote vs. anecdote. Another argument, besides misconfiguration, is the reduced attack surface by removing the huge complexity of sudo entirely. If your argument is basically that its fine because nobody is using the complexity of sudo, then I don't quite understand what your objection is to removing that complexity. You might need to manually restore some env-vars, whats the big deal?

But I suspect this would just turn into a "doing things differently is bad because its doing things differently" argument, its not a very useful conversation to have.

crabbone
0 replies
1h52m

Virtually all users of sudo are using it on their own computer

Nope. If I had to guess, it's in containers, like Docker. And those run in lots of places, and often in places with easy access to company's cloud account, credit card info etc.

bayindirh
6 replies
6h17m

And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things.

Given Lennart already declared SUID concept as “bad”, I think this is the game plan all along.

Systemd: Do all the things, but not very well, and don’t listen to anyone.

lyu07282
5 replies
5h9m

I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?

datadrivenangel
1 replies
4h59m

SUID has flaws, but it's not clear that there are any more convenient alternatives?

1oooqooq
0 replies
1h45m

you missed the memo. it's dbus. (wish i could end with /s)

bayindirh
1 replies
3h30m

SUID mechanism doesn’t always “elevate to root”. It’s a mechanism to “run as another user” and with SGID allows great flexibility in user permission management. You can allow all kinds of (responsible) user switch tricks for multi-admin servers and multi-user systems.

Focusing all of this to sudo and framing SUID as “just implemented to enable sudo” is not painting the correct picture.

Moreover, removing SUID breaks tons of mechanisms and scenarios.

Security of sudo can be debated, but evolving current sudo to a better state step by step is miles better than banishing and rebuilding it and making it dependent on systemd + polkit. systemd already breaks tons of UNIX conventions and way more complicated than it should be.

When you think, it sounds like “conquering” another part of user space mixed with NIH (and we know the best), and making systemd more entrenched. systemd is already a pretty large surface area to attack to begin with.

XZ back door reached SSHd over libaystemd. Do we need another “integrated target” to attack in Linux?

crabbone
0 replies
1h57m

All these ideas that tie permissions to a file completely fail when files need to be accessed either over network, or inside a container.

I can see how the original authors didn't consider these cases, because they simply weren't there yet... but knowing what we know today: SUID is an awful idea.

lucideer
0 replies
2h8m

The problem with this line of thinking is it gives automatic carte blanche to anyone pointing out problems to implement "solutions" to those problems with little interrogation of whether those solutions are actually better.

SUID, like any system, is flawed. Most of those flaws are balanced trade-offs; if you're addressing one you need to be aware of the severity of any counter-problems you're inevitably introducing.

Lennart is well known for criticising existing systems while simultaneously ignoring & dismissing criticism of the proposed solutions - you need to be able to weigh up both sides in a balanced way. Lennart demonstrably isn't.

sfink
2 replies
2h5m

Huh. I'm not at all a fan of how Poettering operates, but it's neither the ideas nor the implementation where I'd fault him. Well, it depends on what you mean by implementation, I guess; I'm talking about the core "how does it do its thing", not the interface by which you use it.

I think Poettering has great ideas and great implementation. It's the execution and interface that are often terrible. If the square peg doesn't fit in the round hole, then he'll always say that the peg is perfect and the world just needs to chisel out the corners of the hole.

1oooqooq
1 replies
1h53m

you have the wrong view point. he just have a different opinion than you.

he single handled managed to fool RH and all distros into turning Linux administration just like windows. systemctl list of services is so inspired by the atrocious windows' admin list of services (which have 3 fields supposed to describe the service, but they all just tell you the name again).

it's no wonder his reward was a job at Microsoft.

but again, he's good in all three aspects. you just disagree on building the torment Nexus that is putting Linux in the "standard certification" target for sysadmins.

superpatosainz
0 replies
5m

It's inspired by Apple's launchd.

mahkoh
0 replies
1h50m

The linked PoC requires that the attacker already has root so that it can disable the default ptrace protection.

lofenfew
0 replies
1h49m

What's the difference between this and ptracing the bash session that you run sudo under?

yorwba
2 replies
10h47m

I don't know what your sudo does, but mine requires the --preserve-env flag if you want the new process to have access to all your environment variables.

The thing you're saying is going to be an endless source of problems should already be an endless source of problems! (And I think I've been briefly confused by some missing environment variable once or twice so far.)

mid-kid
0 replies
10h28m

It depends on whether sudo was compiled with --disable-env-reset or not, it's on by default[1].

Also some variables are inherited regardless (e.g. DISPLAY, TERM), and some useful ones (e.g. HOME) are initialized by sudo, but I can't tell where that's done.

[1]: https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7ff...

crabbone
0 replies
1h54m

Even without the flag, sudo preserves a bunch of stuff. And it's not even consistent. Some implementations preserve locale setting, while others don't for example.

throw0101b
0 replies
6h40m

And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things.

See for example perhaps, "systemd can't handle the process previlege that belongs to user name starts with number, such as 0day":

* https://github.com/systemd/systemd/issues/6237

Never mind that POSIX allows it:

* https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd...

* https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd...

I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.

For anyone curious, see "Systemd v230 kills background processes after user logs out, breaks screen, tmux" from 2016:

* https://news.ycombinator.com/item?id=11782364

keepamovin
0 replies
9h14m

Yeah we had to explicitly set that to No and enable linger to let pulseaudio keep running for users so they can continue to stream sound from their remote browsers in BrowserBox/CloudTabs. Ie at: https://puter.com/app/cloudtabs-browserbox

Your comment was really well expressed btw. Made your thoughts and emotions very clear about this. Inspiring communication skill! :)

KWxIUElW8Xt0tD9
0 replies
4h10m

One binary to rule them all, one binary to find them, one binary to bring them all and in the darkness bind them; in the Land of Lennart where the shadows lie. Bwaahahaha.

wkat4242
29 replies
1d17h

I'm really starting to hate the sub-community in Linux that tries to constantly change it.

I don't want to learn a new network config alternative with every update (Ubuntu changed its net config tool again with 24.04). I don't want an immutable os. I don't want to learn to write new config files. I just want to do what I've been doing but with new packages. If there's a problem with something, just fix it. Don't throw out the whole thing.

I moved to FreeBSD and am happy for its reluctance to change. If there is any, it's usually offering something genuinely new to me as a feature and to boot I only need to learn about it if I need it.

Hardware support is much lower but it's worth it IMO. I had the same irritation with macOS. Every release breaking something essential that was part of my workflow and i didn't want to change. Eventually I did change but away from Apple.

I don't want to change to LennartOS either.

hasselhoftd
6 replies
1d17h

Agreed. I've taken to treating my linux installs like I used to treat Windows: no internet access expect application specific.

For example, I run a Visionfive 2 OpenBSD install with squid, everything else has to go through that.

cyberpunk
5 replies
23h4m

Curious why squid and not pf?

Khaine
4 replies
19h17m

squid is a http(s) proxy and pf is a firewall. They do not do the same thing.

cyberpunk
3 replies
13h42m

I assumed it wasn’t doing tls interception as simply using it to allow/disallow internet traffic from various internal hosts — pf works for that also.

Relayd also does a bunch of similar things and is closely integrated with pf too..

Khaine
2 replies
12h31m

That's fair. I assumed he was using squid to filter/block ads and dodgy websites. You can also kind of do this with pf, but not as well.

cyberpunk
1 replies
10h54m

I use openbsd for that purpose also, but with unbound :}

Khaine
0 replies
6h59m

I used to do something similar with pf, unbound, and squid but on freebsd.

andrewstuart
5 replies
23h13m

I want the change.

I love it when new and better ways are found to do things.

I love it that Linux is constantly improving and moving forward.

I’m willing to accept along the way some things seem to be mis steps (I’m looking at you snap packaging).

I love it that improved network configuration systems are being adopted because network configuration is a pain.

I love systemd and when new stuf comes out from the systemd project I think “gee I’m glad finally someone is taking a wholistic look at and fixing that messy inconsistent evolved corner of Linux and replacing it with well thought out powerful and integrated solution.”

Bring on the change, change is the best thing about computing and software. I own vintage computers but wouldn’t want to live there.

cyberpunk
3 replies
23h6m

I’ve been running Ubuntu boxes in prod since 12.x — there is no “improved” way to put an ip address on an interface besides writing something to a file in /etc, but every update this file changes, or it’s format does.

It’s bullshit and I wish it would end.

Alas, keeps the consultant bucks flooding in when we have to rewrite a load of cfgmgt to go to 24.04 I guess..

iforgotpassword
2 replies
22h49m

I just switch every system to systemd-networkd immediately. The same .ini sytax as for service files, and dependencies are easy to handle, e.g. on one system I have two physical Interfaces eth0 and eth1, I want two vlans on eth0, and then bridge one of those vlans with eth1 and then run a DHCP client on that bridge but at the same time assign an additional IP address. This is dead simple to describe with one .ini file per vlan/bridge. Seriously the first time I feel like I'm not fighting an archaic config syntax, fixing up crap in some post-hook.d script, or give up entirely on any config language and just have a convoluted script setting up everything manually.

It's also easy to explicitly express "weird" stuff like "run DHCP client and use all the config options except the default route". Seriously a couple times I needed to do dumb shit and was like "there's no way they let you do this" but no, there's a way to do it.

And I'm pretty positive the config files will stay stable over the coming years and any new networking features will get appropriate config options in newer versions.

cyberpunk
1 replies
21h56m

Eh, I could. But I'm quite sure that the method of switching to systemd-networkd also requires the same if not much more maintenance as simply changing the ifconfig template every few years...

I really don't care about interface configurations that much. It's an annoyance, but one that's quite easy to fix. I think introducing yet another network configuration here isn't the answer, but my linux fleet just run k8s anyway and network config on the linux level is quite simple before we get into cillium/istio/etc :}

iforgotpassword
0 replies
21h44m

Sure, I made that choice at a time where after upgrading, Ubuntu suddenly wanted netplan, debian stayed with /etc/network/interfaces and I think fedora went with networkmanager. So I though f- it, they all have systemd so I'll give networkd a spin. And never looked back.

So maybe don't just switch out of the blue right now if you've got a working setup, but maybe keep it in mind for the next time. :)

JohnFen
0 replies
22h58m

I love it when new and better ways are found to do things.

I do, too. But I also really hate it when those new and better ways make things worse for me. Systemd does that in a couple of important ways. There is even some network-related startup stuff that I can no longer make work automatically at all. For me personally, systemd is a regression, not an advance.

But I also recognize that the Linux world is not duty-bound to make sure it remains excellent for me, and I've pretty much given up on advocating for my needs in the Linux space. There's no point, particularly with the systemd crowd.

dig1
4 replies
23h43m

This is the main reason why I'm still on Slackware. Pat is keeping the same thing for the last 20-30 years. Sure, he had to introduce some stuff, like NetworkManager or PulseAudio, to keep up with the latest software versions, but every major change is postponed as much as possible. Hell, even systemd is not there yet, and I'm pleased about that.

metalforever
3 replies
23h33m

Same, I am also hiding on Slackware .

trallnag
2 replies
22h29m

So Slackware is your main OS? Or is it just something to play around with?

pwg
0 replies
2h18m

In my case, main, and only, OS.

Rediscover
0 replies
2h4m

Main here, with *BSDs or Yocto-based right behind.

jauntywundrkind
2 replies
22h39m

What complaining. There weren't paved paths before. Whatever one person learned was different from how anyone else did it. Few of the tools had anywhere near the essential capabilities, serving o ly some tiny niche of the use cases in some tool specific limited way.

Look at all the different netsevs supported by systemd-networkd. https://www.freedesktop.org/software/systemd/man/latest/syst... This is a huge list of tools that required a huge assortment of tools to do before, few of which had even part way decent management & fewer still had good init scripts. You used to have to learn from 0 each time, with each tool. Nothing was alike, nothing was as capable, nothing was integrative.

Don't listen to these complainers, for God sake. Your life is too short to get pissed off about well built work together featureful tools being built in a mono-repo fashion.

I'm so tired of the sabotage, so tired of broadscale general refusenik attitudes. This post is absurd. There was nothing to learn before, everything was 100% special snowflake & distinct. None of it was great, all of it was limited. Systemd mono-repo is built of many small pieces, but they couple together and are 100x more learnable. What you learn today will work across whatever system you run across. It's such a a better world, and these "pry it from my cold dead fingers" attitude can keep to that path for all I care, but I wish they weren't poisoning kinds with absurd incorrect negativity & being such magnets for disdain. The world today is fantastic & you rarely see these folks with even an iota of appreciation for how good we have it, never a drop of balance. But hate sells, & unites, powerfully.

lupusreal
1 replies
20h14m

so tired of broadscale general refusenik attitudes

You can use whatever software you like on your computers, but you're not entitled to have everybody else follow your choices because everybody else has exactly the same freedom to choose as you do. And if you want to persuade people to follow your lead, name calling is a bad strategy (much less ethnically charged name calling...)

jauntywundrkind
0 replies
17h9m

The anti-systemd crowd dishes it out like crazy & gets minimal blowback. I'm done letting them be monsters with small minded attitudes, ragging & raging with old crusty attitudes that refuse refuse refuse.

I have heard people use refusenik numerous times & never once has it crossed my mind or seemed remotely related to any ethnic matters. There does appear to be a definition though. Alas. It's a great fucking word, makes me smile, feels well crafted & spry, & I detest giving it up, relinquishing it: but I hereby renounce my previous usage & give it up. Blast. Now there is only absence.

(Also, usually name calling is bad because your insulting someone for being something. New here, but I don't think refusenik in the ethnic sense is at all slanderous or insulting though? It's a comment more upon the totalitarian state & a contravention of Declaration of Human Rights than it is a comment on the person? So I'm not sure that there's any victims to the modern reuse & repurposing of this word, unlike most terms that had some ethnic aspect. Indeed, the extensive & adaptive history of usage of this word seems to show ever growing rift in meaning from it's original use, & little fear that just because there was an ethnic situation we cannot use it... I begin to think you protest too loudly.)

paulddraper
1 replies
23h8m

It's very fair to eschew change for negligible improvements.

But I've also seen the community defend terrible stuff just because.

Look at what happened with the init system. System V, fstab, etc was awful. Doing anything with a reasonable level of robustness was grotesquely obtuse and complicated. And yet it was "perfectly fine" to the greybeards. Alternative proposals were near zero.

I don't have a dog in the networkmanager/netplan fight. It could be that one is irrelevant; given history, I have a hard time trusting what I hear.

sudo has quirks for sure (which is why you see a number of alternatives).

chuckadams
0 replies
21h38m

Daemontools was pretty popular with greybeards, actually. But yeah, daemontools/runit/s6 and company have always been for handcrafted server setups, where the thing about init scripts and unit files is that they're a standard thing a package can supply and have work out of the box with minimal tweaking across distros.

Any serious challenge to systemd nowadays is probably going to have to at least offer compatibility with it. No one is going to rip it all out and start over again (again).

ranger207
0 replies
19h27m

I don't want to learn a new network config alternative with every update (Ubuntu changed its net config tool again with 24.04).

That's really just Ubuntu's fault. Between upstart, Unity, netplan, and snapd, Ubuntu likes to go off and do its own thing for a few years before coming back to what everyone else picked in the first place

pmlnr
0 replies
23h28m

I moved to FreeBSD and am happy for its reluctance to change.

Same here on server. Desktop is still linux.

msm_
0 replies
21h25m

I don't want an immutable os. (...)

But I do. So I use one, and contribute to a project that tries to create one. Am I a part of some sub-community that wants constant change? Or do I just have an unusual use-case and want to support it?

The beauty of OS is that anyone can decide which tool to use, contribute to it, and even fork it.

exe34
0 replies
23h7m

I so want to ditch Linux for bsd, but hardware support, both for my current laptop and future pain in searching for compatible hardware is the only thing putting me off. And my server needs cuda for my AI shenanigans, so probably no bsd there either ...

INTPenis
0 replies
22h51m

That's funny. It's like there are two camps, conservatives, and progressives. ;)

Jokes aside, I just think that life is constant change and the programming industry is a good example of that. Coding practices have improved a lot in the last few years and will continue to improve with new knowledge and new technology. Sometimes it's better to start anew from scratch than trying to adapt old code into new practices.

Btw this is not a young whippersnapper saying this. My first IT job was on FreeBSD and OpenBSD. I was a full-time FreeBSD user from 04 to ~10.

And I remember exacty this gripe back in 2011 when Debian was using one network config, RHEL another. Today I actually enjoy the progress made with systemd, and I'm that annoying co-worker who will give you crap for disabling SElinux.

CoolCold
0 replies
1d16h

To help myself to understand others better, I made some efforts to look and keep looking outside my bubble.

That's not simple though- humans tend to think THEY know better for all others while it's often not.

Say you don't want to have immutable distros, but many want. Android or Talos or even OS for network switches are nice examples.

Linux based solutions and products related community is wide and to keep up with evolution one needs to adapt and adopt changes.

We already see what happens for immutable/stale systems like FreeBSD - even TrueNAS is abandoning it, dying as predicted by experts since 2008-2010.

On other side - nothing stops you from keep using sudo or even choose disto vendor which doesn't use systemd, there is a choice, not thing set in stone.

Say I don't plan to switch to run0 in any near future - first it's not gonna be in any LTS disto, 2nd - it seems to be lacking LDAP based rules and very much likely other important features.

m463
17 replies
12h5m

also worth mentioning: Lennart Poettering

"Poettering is known for having controversial technical and architectural positions regarding the Linux ecosystem"

https://en.wikipedia.org/wiki/Lennart_Poettering

vaylian
13 replies
11h32m

His positions are mostly controversial because he challenges the way things have been done for a long time. Whenever he presents some new idea/architecture my first reaction is often confusion. Why would he change something that has worked so well for such a long time? But then I take the time to read up on the reasoning behind his ideas and then things start to make sense. Even when something isn't exactly broken, there is still room for better solutions.

lupusreal
11 replies
9h5m

He's controversial because numerous times his ego has so severely clouded his judgemental that he refuses to see egregious bugs in his programs for what they are. Just one example: https://github.com/systemd/systemd/issues/6237#issuecomment-...

The "people hate him because he makes new stuff" narrative is just more ego-protecting cope. Many developers of other new systems are widely respected and appreciated because their stuff works and they stay humble. Wireguard and Pipewire devs don't get hate poured on them in HN discussions because their shit works, solves problems people have, and because they know how to deal with people.

magicalhippo
5 replies
8h14m

Or in Linus Torvalds' words[1]:

It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.

[1]: https://lkml.org/lkml/2014/4/2/580

calvinmorrison
4 replies
5h45m

But even then, system service developers don't try to 'own the whole world' so to speak and so they do need to play nicely with others. Mr. Poopering philosophy is the minute a dependencies maintainer becomes a thorn in his side - he absorbs that project into systemd. The distribution packagers follow like starving dogs on a hunt

j0057
3 replies
3h19m

Mr. Poopering

This is childish and petty, I suggest you delete your account.

etc-hosts
1 replies
3h13m

You can't delete your HN account.

j0057
0 replies
58m

Interesting! IANAL, but I think this should be basic functionality, ever since the recent-ish European and Californian privacy regulations. Although I think a quick e-mail to hn@ycombinator.com would suffice.

calvinmorrison
0 replies
3h12m

No thanks!

lupusreal
2 replies
4h54m

His reason, although clear, is also plainly wrong. Such usernames although bizarre may be encountered by SystemD so it shouldn't break when it sees them. Computer programs, particularly important ones, should be conservative in what they emit and liberal with what they accept and that means not breaking when they encounter weird but technically permissible usernames. His response should have been "Golly, that's a weird username, I didn't think that was possible" and then fix the bug.

alserio
0 replies
52m

Disclaimer: I know nothing about the particular bug. Postel's Law has its tradeoffs, and its fuzzy lines are a nice place for security issues to arise.

4star3star
0 replies
2h23m

There is a certain personality type that likes to reimagine that their original thinking was not flawed, even when presented with a detail that they did not incorporate into their original thinking. If the detail had been in their awareness from the start, they would have arrived at a different position, but they are bound to a strict sense of linearity for reasons inexplicable to me except for ego protection.

throw0101b
0 replies
5h32m

3. even `adduser` will not allow it by default

5. useradd does allow it (as noted in a comment). 6. Local users, and the utilities that create them, are not the only source, there things like LDAP and AD.

7. POSIX allows it:

* https://github.com/systemd/systemd/issues/6237#issuecomment-...

cduzz
0 replies
11h21m

There have been lots of suggestions for how to improve linux / unix for a very long time.

The first great war I remember, and I'm sure there were more before I was around, was DJB vs everyone. For the most part, I think his designs, "weird" as they were / are, are still better than almost every crackpot variation of them that's come since.

merpkz
1 replies
10h22m

Is this guy still hated and receiving death threats? Also didn't knew he is working for Microsoft now, that's an interesting career change.

aerique
0 replies
6h54m

And explains so much!

jeltz
0 replies
6h42m

And another of the systemd devs, Kay Sievers, was banned from contributing to the Linux kernel due to his bad attitude and unwillingness to collaborate.

Poettering and Sievers are skilled devs with huge egos.

rascul
3 replies
16h19m

For three decades. I suspect he hasn't seen much money for the work, but hopefully I'm wrong.

skywal_l
1 replies
13h57m

From his personal page:

For the past 30+ years I’ve been the maintainer of sudo. I’m currently in search of a sponsor to fund continued sudo maintenance and development. If you or your organization is interested in sponsoring sudo, please let me know.[0]

[0]: https://www.millert.dev/

lenerdenator
0 replies
7h12m

Sounds like a prime candidate for the Linux, Apache, Mozilla, etc. foundations.

Y'know. Before some strangely-named benefactor from within the UTC+03:00 time zone swoops in.

al_borland
0 replies
13h49m

Seems like that might be an issue.

From his website…

I’m currently in search of a sponsor to fund continued sudo maintenance and development. If you or your organization is interested in sponsoring sudo, please let me know.
maxloh
1 replies
14h33m

So many critical components in our system are maintained by just a random good guy on the internet.

I can't help but think of another XZ crisis that is yet to come.

https://xkcd.com/2347/

BLKNSLVR
0 replies
11h32m

I think this may be the more accurate sentiment:

I can't help but think of all the other xz crises yet to be discovered

citizen_friend
0 replies
12h29m

Did you expect more?

aixpert
0 replies
11h54m

Don't worry I offered him help. I recently helped xz library too

rstuart4133
24 replies
19h11m

I'm not a fan of sudo. It's does so much it needs BNF to describe it's configuration format. Who knows, maybe replacing the configuration with polkit is a good idea. Still it's a stand alone binary with one clear job to do, simple enough that one person has no trouble getting their head around it so it's not surprising it hasn't had too many problems over it's long life time.

This made me smile:

sudo has serious problems though. It's a relatively large SUID binary, i.e. privileged code that unprivileged users can invoke from their own context. It has a complicating configuration language, loadable plugins (ldap!), hostname matches and so on and so on.

That is a bit rich coming from the author of systemd, which must be in the running for one of the largest bodies of code that must run as root. It's also a very complex piece of code. That complexity is the reason I was completely flummoxed by interactions between systemd and dll's being exploited by the XZ utils hack to attack an unrelated and uncompromised binary: openssh. Run0 is just an extension of that ball of mud. It's a stretch to believe it will be more secure than sudo in the long term, which is amusing because it appears Lennarts primary argument is it will be more secure.

I'm not the only one who has noticed this: https://lwn.net/Articles/971812/

dijit
9 replies
18h39m

Regarding your first point: some people agree, most notably the OpenBSD people who did something about it and wrote “doas” as a replacement; which fits the most common use-cases of sudo without fanfare.

logicprog
8 replies
18h2m

And, as LP points out, fails to solve the actual problem because it's still locked into the exact same flawed Unix model, and refuses to integrate with anything else in the system to get things done in a better more systematic way. It's just a slightly refined version of the same tired old Unix way

dijit
5 replies
17h58m

Use something else then?

Linux won on Unix merits.

Feels a bit disingenuous to use that against it, especially when including half the system libs has caused one major and highly publicized security issue already

logicprog
4 replies
17h32m

Use something else then?

What a tiresome response, but here, I'm feeling in a loquacious mood, so I'll humor it.

First, what else would I use? I don't just want a "well designed" operating system, I also NEED an open source, customizable one that is compatible with the vast majority of developer tools and build systems and toolchains — and that is, without a doubt, Linux. I don't have a better option from a practical standpoint.

And even from a design standpoint, there simply aren't any better options, because Unix killed off all of the other good alternatives, and now it's essentially the least worst option we have right now. Basically the same situation we were in when the Unix-Hater's Handbook was written.

I mean, what else have we got?

Windows? Windows NT, by way of OpenVMS so I've heard, had some very interesting ideas that I think Linux would have done well to imitate, like having a Common Language Runtime that lets you directly interact with the objects and functions of every application and code base on your system and communicate with them in structured data (something Lisp Machines and Smalltalk did first, better, but I digress), but we are beginning to get that with DBUS and things like nushell, and Windows failed its own promise there and has a vast panoply of its own flaws, not least being Microsoft. So that's not really better at all.

MacOS? There are many ideas from MacOS I'm a huge advocate of Linux stealing, but it is still fundamentally a UNIX, and in my opinion has even more flaws than Linux has, especially since Apple seems to have stopped caring about their software quality. Not to mention, uh, >Apple<.

So you're basically just pulling the old "you think our social system is deeply flawed in some ways and want to change it? Just go live somewhere else then."

Furthermore, I was never intimating that everything Unix did was completely irredeemable and the entire system we've spent all this time and energy building should be thrown out completely in favor of something entirely new. Instead I was responding to the failure, the refusal even, to develop this amazing testament to open source development and the operating system design sensibilities ties that drive it forward or in any new directions, among a certain crowd that determines the worth of something new by how well it adheres to the philosophy of the old.

I think we can build an excellent new system on the bones of the Unix systems we have now, if nothing else because it's what we've got to start with, and it did sort of have some interesting ideas. I just think it requires actually thinking outside of the box and reanalyzing our dogmatic adherence to tired old traditions in light of everything we've learned and everything that's changed in the interim, and the good ideas from other operating systems that we can borrow, instead of just repeating the same ideas over and over.

A flaw in our modern notion of operating system research and development which has depressed even the creators of Unix themselves: and while I don't think Plan 9 was the right move exactly — I think it actually recapitulates many of the flaws and fallacies of unix, such as the idea that everything being a file is particularly useful, or that we should use plain text designed first for people to read and only secondly for a computer to process, in idiosyncratic formats, instead of structured data — if even the original creators of Unix believe that it should be transcended (Dennis Richie), and that the original philosophy is dead (Rob Pike), maybe we should learn something from that?

Maybe it's actually okay to look at what other good ideas there may be in the problem space instead of being myopically, slavishly devoted to a sad old religion.

Linux won on Unix merits.

First of all, even if that was the case, that doesn't mean it can't improve?

Just because, let's say, it's Unixy design was better than anything else that was on the market at the time, and so it won out against the other options that were available, doesn't mean it is the best possible option — that it can't be improved or developed, or even that the philosophy motivating it wasn't fundamentally flawed and broken in some ways; all it means is that whatever improvements could be made, or whatever was broken in the philosophy to begin with, was less broken or less bad than what happened to exist in competition with it. You're making the exact same mistake that people with conservative tendencies in life me and insisting that just because something work in the past, for whatever reasons it did that, it can't possibly be developed or improved upon. You aren't even saying if it ain't broke don't fix it, you're saying if it wasn't literally the worst, don't fix it.

In fact, I don't even think Unix won out in the server, workstation, academic, scientific, and supercomputing Realms as much as it did because of timeless technical merits and design decisions based on eternal truths that mean we should continue genuflecting to them forever (as much as the purveyors of the Art of Unix would like us to think that) but instead because it happened to have features that happened to be extremely relevant merits in the particular time and place and context it arose in, technologically and economically speaking.

Namely, that it combined extreme minimalism and portability with a reasonable level of composability, even if the composability it offered was awkward and half baked, and because the other offerings had made their own more severe tactical mistakes (Lisp Machines).

Thus it won out mostly almost by historical accident, as most things do, because a proper level of composability and integration, using defined IPC and structured data and well integrated families of tools with non-Turing-complete configuration languages was just too difficult for the hardware of the time, and so the choices were either on operating system with very little composability and flexibility and programmability, or something like unix.

But that isn't the case anymore, yet because it did win, we've retroactively deified it.

We can have our cake and eat it too if we choose to, if we choose to not get sucked in to the North Korea like UNIX cult.

skissane
1 replies
14h23m

Windows NT, by way of OpenVMS so I've heard, had some very interesting ideas that I think Linux would have done well to imitate, like having a Common Language Runtime that lets you directly interact with the objects and functions of every application and code base on your system and communicate with them in structured data

The CLR is Microsoft’s answer to the JVM. It is not among the ideas Windows NT inherited from OpenVMS. It is not part of the core OS. Most apps don’t use it. With the advent of WinRT, there is arguably less of a push for its use than there once was.

And when you talk about “communicating with structured data”, I believe you are talking about PowerShell - which apps don’t participate in by default, you need to go to the extra effort of writing PowerShell cmdlets for your app, and many developers don’t. You have to write them in PowerShell itself, or else a CLI language such as C#, F#, C++/CLI, etc. So if your app is written in C or (standard) C++ or Go or Rust or Python or Java or JavaScript or Lisp or whatever, integrating with PowerShell requires adding a new language to your project - no wonder many don’t bother

logicprog
0 replies
6h41m

Makes sense. Like I said, there are a few vaguely interesting ideas on Windows but it isn't good at all.

rixed
0 replies
13h54m

Unix "way":

- what matters is composability (ie programs, possibly running from different computers, being able to use each other's output)

- simplicity is required for composability. Thus the structure less file system and the "everything is a file" design concepts.

The same merits as HTTP in the realm of protocols.

The appeal for a stricter and more principled approach are understandable, and the road one end up favouring largely depends on one's early experience I believe.

I, for one, grew up in a world where I could use either a resilient Linux system that could run a treasure trove of programs written long ago for different machines, or a more modern and principled OS (windows) where a small glitch in some non essential video driver would frequently bring down the whole thing. I went for linux, it won maybe for its merits, maybe by chance, and now I'm concerned that a whole encompassing systemd will eventually bring us back where an unrelated glitch, or backdoor, in an unrelated non essential part will bring down the whole system.

grosswait
0 replies
16h45m

Way too loquacious. Definitely not the Unix way.

llm_trw
1 replies
15h3m

If you don't like Unix maybe don't write software for a Unix clone.

logicprog
0 replies
6h39m

It's the best (or, least worst) OS we have right now, though, I just want it to evolve on those Unix ideas.

mzi
6 replies
18h38m

Isn't that link showing the opposite? That sudo is really large and systemd isn't? They even compare systemd with wpa_supplicant and it turns out they are the same size.

rstuart4133
5 replies
18h27m

Not really. I'm not going the effort of breaking it down like he did, so just looking at total lines in the source calculated with "wc -l $(find . -type f)":

sudo: 284,103 systemd: 1,981,535

logicprog
4 replies
18h5m

I find your comment here sadly indicative of the level of discussion around systemd from its haters.

Your metric is utterly misleading not only because you're almost certainly counting non-code files, but more crucially, because the systemd repository contains the code for *sixty-nine* entirely separate binaries, separate tools under the overall systemd project umbrella, so counting their collective code size as if it is the code base of one single gigantic tool, a single gigantic program that compiles into a single gigantic binary, with all the interweaving that implies, is just disingenuous at best. That number does not represent the size of a single attack surface area, and pretending it does is nonsensical. It's like pulling in the source of all of gnu and doing a line count. And for the record, I've actually done this properly, cloning the systemd repository and then reading the documentation to figure out what directories and source files did what, and assembled a list of the directories and source files that represented just systemd-the-init-system, and got about 240,000 lines of code.

And remember, it won't actually be systemd the init system that will be replacing sudo, it will be systemd-run, which is a separate binary, with a separate memory space, and a separate permissions model, that merely communicates with systemd the init system to get certain things done. I guarantee you it's probably smaller than the code base of sudo, and this architecture, as LP points out if you actually read his thread on mastodon, far better represents the methodology of running things with at least privilege and privilege separation and so on, because instead of having the binary that is called from unprivileged space managing transitioning itself into privileged space and then doing things, instead the binary always stays unprivileged and just communicates via a strictly defined IPC protocol that gives it no direct abikity to do anything with a process that was already privileged instead, that can decide what to do on its own.

Let me leave you with this quote:

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

https://0pointer.de/blog/projects/the-biggest-myths.html

rstuart4133
2 replies
17h46m

Two things:

- Non code files were counted for both sudo and systemd. That's because I'm lazy, not because I think it influences the result one way or the other (I don't what effect it would have).

- Separate binaries are not separate logical entities. Pointing to separate binaries is a misdirection. systemd is a set of binaries cooperating using RPC (dbus) to yield something bigger than any single binary. The biggest hint they are interconnected is they are in one source ball for a reason: so these binaries can share a lot of code and interact in complex ways.

As for systemd-run being "a separate binary, with a separate memory space, and a separate permissions model", those things didn't protect openssh being hit with the XZ Utils hack via systemd. An unexpected interconnection is more than enough. systemd abounds with interconnections. Being tightly interconnected often gives you greater functionality, and in the case of Run0 I suspect that is going to be a big win because systemd has a lot of process isolation mechanisms built in. But complex interconnected systems achilles heel is security, and that's definitely true here.

rixed
0 replies
14h22m

But complex interconnected systems achilles heel is security, and that's definitely true here.

And portability. Sudo, being a truly independent binary, has been ported in many OSes. Run0?

The issue with systemd ecosystem is not primarily technical, it's the isolationism.

jchw
0 replies
17h6m

Separate binaries are not separate logical entities.

They're separate programs, sometimes essentially completely independent, sometimes sharing almost no code at all. For example, systemd-init does not have dependencies on all of the other programs, or vice versa. You can use the systemd-boot bootloader without using systemd's init daemon. You can use the systemd init daemon without using the systemd-boot bootloader.

Having separate release tarballs isn't some special distinction that makes things more "logically separate".

Besides, isn't this a goalpost shift of epic proportions?

That is a bit rich coming from the author of systemd, which must be in the running for one of the largest bodies of code that must run as root

The point in indicting the size of systemd was the code that runs as root, but the wc line count is counting tons of stuff that not only doesn't all run as root, but some of it doesn't even run under Linux.

those things didn't protect openssh being hit with the XZ Utils hack via systemd

A lot has already been said about this before, but the systemd library that they included in the Debian and Fedora patches to OpenSSH is by far one of the smallest surface areas of any of the runtime dependencies. A bit ago, when I ran libtree on sshd, I got this:

    $ libtree `which sshd`
    /run/current-system/sw/bin/sshd 
    ├── libgssapi_krb5.so.2 [runpath]
    │   ├── libkrb5.so.3 [runpath]
    │   │   ├── libk5crypto.so.3 [runpath]
    │   │   │   ├── libkrb5support.so.0 [runpath]
    │   │   │   │   ├── libkeyutils.so.1 [runpath]
    │   │   │   │   └── libresolv.so.2 [runpath]
    │   │   │   ├── libkeyutils.so.1 [runpath]
    │   │   │   └── libresolv.so.2 [runpath]
    │   │   ├── libcom_err.so.3 [runpath]
    │   │   │   ├── libkrb5support.so.0 [runpath]
    │   │   │   ├── libkeyutils.so.1 [runpath]
    │   │   │   └── libresolv.so.2 [runpath]
    │   │   ├── libkrb5support.so.0 [runpath]
    │   │   ├── libkeyutils.so.1 [runpath]
    │   │   └── libresolv.so.2 [runpath]
    │   ├── libk5crypto.so.3 [runpath]
    │   ├── libcom_err.so.3 [runpath]
    │   ├── libkrb5support.so.0 [runpath]
    │   ├── libkeyutils.so.1 [runpath]
    │   └── libresolv.so.2 [runpath]
    ├── libkrb5.so.3 [runpath]
    ├── libcom_err.so.3 [runpath]
    ├── libk5crypto.so.3 [runpath]
    ├── libz.so.1 [runpath]
    ├── libcrypto.so.3 [runpath]
    │   └── libpthread.so.0 [runpath]
    ├── libldns.so.3 [runpath]
    │   ├── libssl.so.3 [runpath]
    │   │   ├── libcrypto.so.3 [runpath]
    │   │   └── libpthread.so.0 [runpath]
    │   └── libcrypto.so.3 [runpath]
    └── libpam.so.0 [runpath]
        └── libaudit.so.1 [runpath]
And that's just what you can see by looking at the shared objects, there might be more at runtime.

You would have to ignore mountains of rationality in order to come to the conclusion that systemd was remotely reasonably "at fault" for what happened with the xz incident. Not only that, even prior to the xz incident, systemd had already fixed the problem that lead to the xz exploit, it just wasn't shipping in Debian or Fedora yet; that's most likely why the xz backdoor had to be rushed into the next releases in the first place, because the window of opportunity was closing.

diath
0 replies
17h2m

His methodology actually favors systemd, as sudo is for example vendoring its dependencies in the repository.

    diath@11km :: /tmp » git clone https://github.com/systemd/systemd
    diath@11km :: /tmp » cloc --match-f="(c|h)" systemd/src
    C                             1478         165173          37638         584876
    C/C++ Header                  1083          15580          22432          59692

    diath@11km :: /tmp » git clone https://github.com/sudo-project/sudo
    diath@11km :: /tmp » cloc --match-f="(c|h)" sudo/{src,include}
    C                               41           2104           3359          16384
    C/C++ Header                    36            797           2159           5158

georgyo
1 replies
18h37m

The article you linked seems to be in support that systemd is in fact simpler than sudo.

Sudo, which only does privilege escalations, is only 1/3 the amount of code of the entirety of systemd.

Systemd-run has been around for many years now, this is simply an expansion of capabilities of features already exposed.

infotogivenm
0 replies
14h5m

Em, that seems an extremely generous comparison, where did you come up with that? Last I checked for example systemd relies on polkit for policies, which drags in a javascript interpreter engine. If the author thinks BNF is complex…

repiret
0 replies
15h0m

I initially had the same reaction although having read the whole thread, the author convinced me that SUID is in fact a fatally flawed architecture and that run0's client-server architecture is correct.

klysm
0 replies
17h58m

That is a bit rich coming from the author of systemd, which must be in the running for one of the largest bodies of code that must run as root.

Not really a far comparison given that it’s an init system

flaptrap
0 replies
18h20m

sudo: what, the problem is its attack surface is too big? Nothing like systemd's.

Right now systemd, PID 1 won't finish on a Debian 12 (upgraded) which I am slowly debugging. Neither journalctl nor syslog record messages that flash on the screen. Systemd goes into a dark-flash-dark loop. The developer should focus on getting systemd to work right before pointing at others' supposed deficiencies. Software need to handle error conditions and keep on plugging, especially if it replaces init.

kevincox
16 replies
1d2h

One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways.

This is an interesting offhand comment. You could implement a very similar tool by SSHing to localhost.

m463
4 replies
19h42m

I had to write an ssh client for an embedded system long ago.

Looking at the design, I found it to be sort of messy.

You could restrict commands ssh could invoke, but it didn't seem super secure.

Also scp/sftp was not well designed. You basically had to give ssh access to your system to allow a file to be copied, and there were no real path restrictions.

I personally thought ssh could be much more robust in what you could run and what you couldn't. And scp/sftp could have better filesystem semantics so you could have more security in what you could access.

And I thought having a write-only scp would be really interesting, sort of like a dropbox for people to send you files securely, but not have to give someone ssh credentials to do it. And an anoymous scp/sftp for distribution or a dropbox could have been really interesting too.

metalspoon
1 replies
18h5m

Well, yes, rsync to replace scp. Sftp's also regarded a hack anyway imho.

The write-only scp intrigues me. I guess it's not hard to write a program to do that. But, right, that's not easy with standard tools only. The Linux file system was also not designed for that (although it doesn't prohibit such software) I guess.

eru
0 replies
12h45m

The Linux file system was also not designed for that (although it doesn't prohibit such software) I guess.

There's no 'the' Linux file system. There's plenty of file system to choose from.

And, in fact, it would be relatively easy to write a write-only filesystem with FUSE. (https://en.wikipedia.org/wiki/Filesystem_in_Userspace)

CraigJPerry
0 replies
12h27m

> And I thought having a write-only scp would be really interesting

I think you can achieve that at the file system level. At least, a long long time ago I maintained a public server with exactly that functionality. I’ve forgotten the details now but if I were tasked with this today my first attempt would be add a sticky bit like we do with /tmp: chmod +t dropbox/

If you don’t want to allow me to delete or overwrite my own files I believe (but haven’t tested) that chattr +a on the dropbox dir would achieve that.

Arnavion
4 replies
22h52m

Technically `sudo -u` can switch to any user on the system while only a limited few would be allowed as ssh targets. Even root might not be allowed as an ssh target if `PermitRootLogin` is set to `no`, which I do on all my systems.

pmontra
1 replies
22h17m

I do use that a lot

  sudo -H -u user bash
after I ssh into a server with my own account. That other user might even be a no login account.

noinsight
0 replies
20h28m

You can just use `-i` instead of `bash`. (This method indeed requires a shell configured, your method is needed with nologin.)

fsckboy
1 replies
16h6m

Even root might not be allowed as an ssh target if `PermitRootLogin` is set to `no`, which I do on all my systems.

would something like PermitRootLogin=localhost punch an enormous hole in your intricate opsec?

jimbobthrowawy
0 replies
14h3m

I've set up tor on some machines to forward ssh as a hidden service for an easy to configure way to get past NAT before. That shows up as a login from localhost. (could be configured differently, with some extra work)

There's so ways to configure access to a system, each with footguns I'm surely unaware of.

TachyonicBytes
3 replies
19h4m

It's the usual way to make changes to a privileged file in Emacs; ssh to localhost with root.

tristan957
0 replies
17h0m

Why not use sudoedit?

terinjokes
0 replies
18h3m

'sudo' and 'doas' are inline connection methods in TRAMP, so no need for SSH to localhost. Curious that systemd-run isn't already supported, but I imagine that will quickly change.

lanstin
0 replies
15h23m

I like to have one of my tmux windows be a sudo session with emacs running as root and mostly used to run emerge world or apt update etc. also a window tailing all the logs. I haven’t been on a machine where more than one admin was logged in at the same time in quite some time.

yegle
0 replies
22h23m

In my previous job, we set up a privileged account on a server with shell set to `git-shell`, leave some shell scripts in $HOME, so that we can do:

ssh user@privileged-commands ./do-something
ccorcos
15 replies
11h59m

Can someone explain what this is / how it works to someone who has done a considerable amount of programming but lacks this kind of operating system level knowledge?

I was under the impression that ‘sudo’ was baked into the entire system. Like ‘cd’ or ‘ps’. How exactly can you just swap out sudo? Does that involve swapping out chmod as well?

anon291
3 replies
11h47m

Sudo is a program that:

1. Parses the sudoers file to check if the current user can run the command provided.

2. If so, authenticates the user using PAM.

3. If both those pass, sets the user id to root and runs the program.

There is nothing special about it. All steps can be done by any program. In fact sudo is usually not even an installed by default package in many systems.

The only seeming magic bit is part 3, where the program sets it's user id to root. Obviously if any program could do this... That'd be unsafe.

However, unix systems allow any executable file to have their flags changed to include the setuid bit which causes the file to execute with privileges of the files owner. You'll notice that the sudo binary has this bit set and it's owned by root, which explains now the entire process.

Galanwe
2 replies
11h16m

Just to highlight some of the complexities of `sudo` to complement your helicopter view:

- Sudo can use PAM, or any other means, depending on NSS (local, ldap, through PAM, etc)

- Sudo can use a sudoers file, directory, or even LDAP fields to resolve accesses.

- Sudo can temporarily cache and forward authentication to avoid constantly retyping passwords

- Sudo can elevate you depending on your group, user, or even a glob of the command you want to type

- Sudo can log and report the executed commands

- Sudo can import none, part or all of your environment to run its command

- Etc

Sudo is very complex

cookiengineer
1 replies
10h18m

The setuid part is where things get exploitable. Pretty much any exploit to date was abusing a library's assumption about what to sideload or what to persist after it got root rights for whatever reason.

"Good distro maintainers" (e.g. Arch Linux) try to minimize the attack surface by modifying their packages to use the capabilities flags instead (e.g. the net cap flag for ping binary).

"Bad distro maintainers" blame the end user for their own responsibility for letting this happen. They could have just uninstalled the program, right?

Well, I disagree. SystemD's new approach is that they try to reuse the seccomp sandboxes they've introduced for a while now, where root rights-given processes can even be executed in a chroot, with a fake /etc/passwd file, with fake users, with fake /dev ices etc.

As SystemD as the process #1 always has to be executed as root, I think it's a good thing that they try to offer a sandboxed alternative. Polkit is just so damn ugly with all their hacky subscriptions and policy files. If you disagree with me, I recommend you to learn more about privilege escalation exploits on POSIX systems, and how PAM, Polkit and pretty much any auth framework always said it's the users fault.

LD_PRELOAD auth bypasses are now more than 18 years old, and the CVE still works on enterprise-grade linux distributions. It literally was the reason muslc was created as an alternative to glibc. And that's older than a decade now.

Check out https://gtfobins.github.io (or the Windows NT equivalent LOLbins) if you wanna know how many binaries there are as an attack surface.

dijit
0 replies
6h39m

Honestly though, elevating privilege is inherently the exploitable part of any program that attempts to cover this space.

I would guess you are arguing in a reduction in complexity, which is semi-ironic as run0 is including polkit (and thus: an entire JS interpreter) among other things; while at the same time doas/sudo-rs exist as simpler implementations.

AFAIK, lots of the bloat of sudo is preventing a lot of the attacks you mention though, but I seriously doubt any privilege escalation system doesn't have any weak parts that need heavy scrutiny.

tommica
1 replies
11h54m

Pretty sure `sudo` is an application that you can remove, it just comes pre-installed in many distros.

gattilorenz
0 replies
11h49m

Not only that, but it became commonly included only about 20 years ago. I spent my first years with Linux calling ‘su’ instead.

I still run some very old distribution (e.g. RedHat 6.2) on a Pentium 1 laptop, and I downloaded the source of sudo and compiled it on it, since the sources were not even included in the extended CD set.

michaelt
1 replies
6h16m

> I was under the impression that ‘sudo’ was baked into the entire system.

There's a capability baked into the entire system named 'setuid' which allows certain binaries run by a user to access things as if they were root.

For example, when a user changes their password using 'passwd' that executable gets special write access to the file containing hashes of all users' passwords. The system's security relies on passwd being coded carefully enough that it won't let one user change another user's password, no matter what input they give it.

sudo is "just" a setuid binary, which checks if the user is allowed to run things as root and if so uses its power to run them. It can be replaced.

There are a bunch of design implications resulting from the way setuid works - for example, the operating system has a special setting so if you plug in a USB drive containing a setuid binary, the setuid bit on it gets ignored. So you can't make a special version of sudo at home which doesn't check permissions, then take it to the school computer lab and have it work there.

cesarb
0 replies
4h20m

There's a capability baked into the entire system named 'setuid' which allows certain binaries run by a user to access things as if they were root.

It's actually "to access things as if they were the owner of the binary" (which usually is root, but that's not required).

The problem with that, is that other than the uid, the program inherits everything like a normal program. Environment variables, current directory, open file descriptors, and so on. If the program (and the dynamic linker it uses, and any library it uses including the C standard library) is not very careful, it can be tricked through these inherited things to do unexpected actions while being able to access things as if they were root (or whoever the owner of the binary is). For instance, some environment variables tell the dynamic linker to load extra libraries, or to change from where it loads libraries; these have to be ignored when running as a setuid process.

apexalpha
1 replies
11h54m

sudo, and even cd and ps you mention are simply binaries that come shipped with your distro / OS.

They, like explorer.exe on Windows, are an essential part of that OS with special privileges and roles but they are not part of the kernel, they are still simply programs. It is not developed by the people who develop the Linux kernel.

There are other Sudo alternatives such as DoAs already.

csande17
0 replies
11h44m

While some systems include a "cd" binary, it's basically useless since it just changes its own working directory and then exits.

Instead, "cd" commands are generally parsed and executed by your shell (/bin/sh or similar) directly so that the shell's working directory gets changed and you can run subsequent commands in the new location.

"ps" on the other hand is indeed just a normal program. Usually it reads files in /proc to figure out which processes are running.

ErikBjare
1 replies
11h51m

sudo is just another program, it's not "baked in" as such. It just ships with many (not all) distros. I remember having to install it from repos in the past on a new system: https://github.com/sudo-project/sudo

ErikBjare
0 replies
47m

Reminds me of an assignment I had at uni to implement sudo in C. You get elevated permissions using the setuid bit, and can verify the password of $USER against /etc/passwd.

stouset
0 replies
11h39m

I was under the impression that ‘sudo’ was baked into the entire system. Like ‘cd’ or ‘ps’.

Neither of these are “baked into the entire system” for any meaningful sense of the word. `cd` is just a shell builtin and is casually reimplemented in every single shell. It’s just environment state within your session. `ps` is just a binary that (on Linux) parses stuff in /proc.

None of it is magic. Neither is sudo. It’s just a binary like any other (though in sudo’s case, it’s setups, which is how it can cross the permissions boundary).

keeperofdakeys
0 replies
11h27m

Any linux process can run with elevated privileges (ie: as root) by setting a specific permission bit - https://en.wikipedia.org/wiki/Setuid. This is used for many things like ping and sudo.

Instead Run0 is using systemd to elevate privileges.

There is a lot that could be said, but suffice to say you can have both sudo and Run0 installed. So even if a Distro ships Run0 by default, you can always manually install sudo.

Jonnax
0 replies
11h50m

Sudo isn't baked into the system. It's an application.

https://www.sudo.ws/

Did you read the thread linked?

Xeamek
15 replies
21h20m

2 weeks ago I didn't understood the systemd hate. But I tried to run udev-requiring program on non-systemd based distro.

And now I don't like systemd anymore.

suprjami
7 replies
20h42m

So, you don't like a component because you ran software which requires that component, and you intentionally ran it in an environment without that component.

That does not make sense to me?

vpzom
3 replies
20h37m

The popularity of systemd encourages people to require it, which is the major problem

that said iirc udev was formerly separate and active forks still exist

JoshTriplett
2 replies
20h3m

The popularity of systemd encourages people to require it, which is the major problem

The usefulness of systemd encourages people to require it. Projects most often require it in cases where either there isn't an alternative, the alternative isn't maintained, or the alternative is missing functionality.

Xeamek
1 replies
18h41m

Self perpetuating growth. Systemd integrates many functions so people default using it and add even more functionality that bring even more people into ecosystem.

Which is basically how every tech ecosystem works.

The problem is that linux is supposed to not be just_another_centrally_controlled_ecosystem, so when systemd abuses their popularity by enforcing whole ecosystem (rather then cut itself into separate pieces), that is worrying

JoshTriplett
0 replies
1h56m

It seems like you're attributing to perceived malice ("enforcing") what is better explained by a combination of trying to get things done and not prioritizing replaceability higher than the benefits of integration. In other words, a project that simply has different priorities.

It turns out that many other people also like seeing stuff get done more so than they care whether the project in question is trivially replaceable.

Xeamek
1 replies
18h51m

No.

I don't like a framework that promotes using components that are arbitrary dependent on it.

To use udev, I need systemd-init, and to use systemd-init I need systemd boot.

I really don't believe it MUST be this way, and those requirements aren't at least partially arbitral.

Why systemd refuses to run in chroot?

BenjiWiebe
0 replies
14h12m

You don't actually need to use systems-boot to use systemd-init. They're two separate things.

rezonant
0 replies
20h40m

Well, I tried to run a Mac binary on Windows and it didn't work, so now I don't like Mac.

deadbunny
3 replies
20h13m

I tried filling up a Tesla at a gas station.

And now I don't like electric cars anymore.

lupusreal
2 replies
20h0m

You joke but the inability of BEVs to make use of the gas station infrastructure is probably their number one obstacle to mass adoption.

shrimp_emoji
1 replies
19h37m

You just rent some parking space for the charge pylons. Probably off to the side where the self-service wash hose/tire pump usually is.

vdqtp3
0 replies
17h47m

The energy bandwidth of a charger as opposed to a gas pump is a huge issue right now.

Gas pumps can easily pump up to 10gpm [1], corresponding to 300 miles of charge in 3-5 minutes as opposed to Superchargers, which take 15 minutes to charge enough for 200 miles of driving[2].

When this is improved, it will make BEV's much more acceptable to many people.

[1] https://en.wikipedia.org/wiki/Gasoline_pump#Design

[2] https://www.energysage.com/ev-charging/tesla-supercharger-gu...

bhaney
2 replies
20h34m

You must absolutely despise libc

lmm
0 replies
20h9m

libc has multiple independent implementations, if you don't like one you can switch to another. Software that hard-depends on a specific libc is indeed to be despised.

Xeamek
0 replies
18h47m

The difference is that I can solve libc dependency at comp time (statically linked against it), while systemd dependencies require runtime support.

akagusu
13 replies
1d2h

Piece by piece, Red Hat is taking over the Linux ecosystem.

izacus
8 replies
1d2h

Well, they're the only ones actually funding development of the ecosystem, aren't they?

The rest just do a lot of opinoning and complaining and not that much of developing.

superkuh
7 replies
1d2h

The implicit premise of this comment is that linux is broken and needs to be changed. It isn't. The changes are not inherently good. Development is not inherently good. Just look at Gtk3 from 2014 to 2024. It was far more functional in 2014 (re: keyboard input) and now that has been removed because "progress".

throwaway11460
4 replies
1d1h

Nobody needs to adopt the changes. Everybody did because it's better than the alternatives. There are still systemd-less distros if you like it.

superkuh
2 replies
1d1h

My issue is not with systemd. My issue is with the argument that all development is good. In this example I am pointing out how Gtk3 has suffered from development attention from GNOME over the last decade and became worse.

Maybe run0 is worse than sudo. Maybe not. I have no personal experience on that topic and I doubt anyone here does.

throwaway11460
1 replies
1d1h

It's the same thing though - nobody is forced to accept their changes, you can fork at any time. Or stop using it, keep using gtk2, etc.

immibis
0 replies
1d

Reality is more nuanced than that, because even if the newer software is worse, if it markets itself better it can persuade other projects to drop support for the old software.

thecrash
0 replies
1d

Yes, theoretically we could just stick with old software that was perfectly good at the time. The problem is that the ecosystem moves together - there's an emergent consensus about what is "current" (i.e. what's obligatory to support) across many different projects.

So each component is interrelated, and holding one back means sacrificing compatibility with the new features (and security fixes!) of many other components.

In this way we can find ourselves dragged into using software that is actually worse than it used to be. This is important to note because it means our use of a component is not proof that it's good. It just means that the ecosystem is good enough overall that it can force us to accept devolved versions of certain components.

It makes sense to argue about what the consensus of the ecosystem should be even while recognizing that we will probably accept it regardless.

sophacles
1 replies
1d1h

No one is stopping you from running a 2014 version of your favorite distro. Seems like a good way to address your concerns.

superkuh
0 replies
1d1h

Indeed. I have been using Ubuntu 14.04 under ESM for the last 10 years. But that ESM support is ending in 2024. I've tried modern distros using modern Gtk3 and they're lousy with file chooser bugs. I've tried patching Gtk3 gtkfilechooserwidget.c myself but I can only fix it for the first file->open dialog, not subsequent ones. Attempts to get help in #Gtk over the last 5 years have been rebuffed in IRC and ignored/closed repeatedly on the issue trackers: https://gitlab.gnome.org/GNOME/gtk/-/issues/5872

cozzyd
1 replies
1d2h

Ironically enough, Lennart now apparently works for Microsoft.

(though to be clear, I like systemd and I think Lennart is a very good engineer).

oceanplexian
0 replies
23h35m

That’s a great fit for him since systemd appears to lift their monolithic design practices and force them on the Linux community.

immibis
0 replies
1d

We don't have to use their stuff. systemd actually does a good job of managing services' up and down state - it's the rest of the bundled functionality that people take issue with - and if service up and down is all you want, there's runit.

Wayland seems to be a solution without a problem, and it's only winning by default. I've toyed with the idea of forking Xorg - the code is a bit odd by today's standards, but I didn't find any direct problem with it, and it works fine - the biggest problem I discovered in Xorg is a lack of project management as nobody knows what it should and shouldn't do

My gentoo system has some gentoo-specific fork of udev without systemd in it.

We don't have to use run0 and can just use sudo.

Spivak
0 replies
1d2h

I guess but in this case it's doing something that sudo doesn't do — get privs from a daemon instead of setuid, and using something that systemd already did (systemd-run).

Is it that weird that they would make a runas frontend when all the pieces of it were lying around?

ezoe
12 replies
1d7h

I wonder what other existing programs Will Systemd attempt to replace in the future.

My bet is /bin/sh, maybe they went further to replace the entire POSIX utilities.

quectophoton
4 replies
21h4m

filesystemd, replacing ext4/btrfs/etc.

It will come with `filectl` for all your file operations, so you will no longer need `cd`, `pwd`, `touch`, `rm`, `mkdir`, `cat`, `grep`, `find`, etc. Instead you do everything through `filectl` commands.

This will deprecate many commands from GNU coreutils, which is a good thing because replacing things is always good.

Then, since programs are just files, and filesystem will be part of systemd, any program you want to use will obviously have to go through systemd as well, meaning they will need to be a service unit of type `oneshot`, because this way we keep everything well integrated together.

Don't worry tho, you only write the unit files once and they work forever. The only thing you need to remember is that, instead of `cargo build` you'll need to use `filectl exec -u cargo build` (`filectl exec -u` is only 3 words, so you don't have the right to ever complain about this tiny little change).

Anyone who doesn't like these changes is stuck in the past.

woku
0 replies
5h23m

You will no longer need `cd`, `pwd`, `touch`, `rm`, `mkdir`, `cat`, `grep`, `find`, etc. Instead you do everything through `filectl` commands.

This is not as ridiculous as it sounds. Arguably, the file system is more of an exception, because it is directly exposed by the kernel. But, for example, to manage the files in a tar archive you do everything with the `tar` command and to manage a git repository you do everything with the `git` command.

jimbobthrowawy
0 replies
13h56m

busyboxd?

imiric
0 replies
19h0m

The only thing you need to remember is that, instead of `cargo build` you'll need to use `filectl exec -u cargo build`

No, you forgot about `buildctl` which compiles any language into systemd bytecode, that runs on the systemd VM. At long last, write once, run anywhere!

foresto
0 replies
19h56m

instead of `cargo build` you'll need to use `filectl exec -u cargo build`

You joke, but I already have to do this with lxc commands, and the systemd-compatible version of those commands is even longer than you imagined. See my other comment for details.

anthk
3 replies
23h23m

Guix will reimplement POSIX utils and extras with tools written in Gule.

smegger001
2 replies
21h29m

Please say this is a joke

anthk
1 replies
19h57m

https://nlnet.nl/project/Gash/

It wouldn't be a bad idea. Also, Guile's JIT could be interesting there.

Also, a shell with a live REPL instead of failing on errors can be pretty interesting.

zarzavat
0 replies
12h50m

“gash” oh my, what a name. Do you think they know?

vbezhenar
0 replies
7h31m

Hopefully glibc and coreutils!

samgranieri
0 replies
18h46m

Let’s call it GNU/systemd/linux

rcxdude
0 replies
9h13m

I mean, it already has replaced the shell in a lot of ways. Systemd is basically the one reason why it's feasible to banish POSIX shells to where they belong, albeit still not usually practical.

StimDeck
8 replies
1d11h

Just a reminder that there are plenty of systemd-less distros available. Also a reminder that those distros would have been safe from the nearly-solar-winds-level backdooring of Linux distros from XZ utils.

Jonnax
3 replies
1d9h

That backdoor was never pushed out of the testing branches for distros.

wpm
0 replies
1d6h

Oh well I guess it didn't matter then.

StimDeck
0 replies
1d8h

Not sure of the relevance of this comment, can you elaborate? Were you the one that caught it? Our balls were inches from the bandsaw. Systemd made it possible to compromise SSH through an unrelated, single-maintainer lib that wasn’t even a dependency.

Edit: never mind, I see you are a systemd crusader.

Arnavion
0 replies
22h58m

It was in OpenSUSE Tumbleweed for a few days actually (RPM-based + rolling release + did the sshd patch). I was affected by it and it was fun watching the reliable ~100ms difference in `time /usr/sbin/sshd -h` with and without `TERM=foo`

nialv7
2 replies
22h7m

Can you even hear what you are saying? Don't you find it ridiculous to blame the XZ backdoor on systemd, instead of the actual hacker?

Even if systemd did not exist, the hacker would have just picked something else to infiltrate.

pessimizer
0 replies
19h42m

Don't you find it ridiculous to blame the XZ backdoor on systemd, instead of the actual hacker?

This is a great argument against all computer security. If you believe in securing your computer, you're supporting hackers. Because if you ever believe that a lock has failed, you're saying the thief is innocent; that's how logic works.

bitwize
0 replies
21h24m

Of course, the actual hacker was to blame, but systemd was implicated. The fact that the attacker was willing to settle for compromising just Debian and Red Hat systems indicated that they perceived the path from xz to libsystemd was the easiest way to effect the backdoor and that doing it any other way would have been too much work for marginally little gain (Red Hat and Debian systems being so common).

ranger207
0 replies
19h32m

Also remember that systemd-using distros like, say, Arch were also safe from the nearly-solar-winds-level backdooring because the backdoor targeted specific distros widely used as servers. Obviously the solution to security from backdoors is only using distros that aren't popular for servers

abridgett
7 replies
1d1h

I'm not sure it can replace non-trivial setups - sudo/doas looks set to stay.

e.g when you need to restrict a set of users to run only certain applications with certain other users. sudo can do this (even if the config format can be painful).

akira2501
2 replies
21h49m

If the lesson of xz was "reduce supply chain attack surface" then the freedesktop people clearly haven't received it yet.

bmicraft
1 replies
17h2m

Fedora has used PolKit for 12 years now, and the javascript rules have probably been a thing for about as long.

akira2501
0 replies
8h18m

Doctors recommended cigarettes for decades. What should give everyone similar pause is xz was found unintentionally.

rcxdude
0 replies
20h21m

It's a heck if a lot better than a random smattering of shared libraries getting pulled into a random high-priviledge context which also inherits some other context from whoever is asking for authentication. Polkit gets a lot of flack but PAM is absolutely mad.

stop50
0 replies
23h3m

Thats why i moved every sudoers rule to ldap. Much nicer to configure and no need for files with the same content on multiple servers. New users are added and removed fast and i can check the rule on any server.

lupire
0 replies
1d

What's the goal?

If the host is to get most scenarios off sudo, exceptions aren't a problem.

If the goal is to delete sudo, exceptions matter, and migrating what is migratable will clarify what the remaining requirements are.

rahen
6 replies
1d11h

I thought doas had solved this already.

progval
4 replies
1d11h

doas uses SUID

bandrami
3 replies
1d11h

It either has to be SUID or it has be a daemon running as root (or with enough caps to make the difference not matter). Adding a needlessly verbose configuration ecosystem doesn't change that. I imagine there's going to be some cool stuff this can do with homed and userctl, but it's not like the fundamental problem of "this program can grant root privileges" can ever go away.

dale_glass
2 replies
1d10h

The problem is not "this program can grant root privileges", it's that the setuid bit sucks.

Linux processes inherit a lot of state from the parent which means it's absolute hell to make a secure setuid binary. And at any time the Linux kernel can add a new feature which will be inherited by a child process, but that the process can't defend against because it wasn't even a thing when the code was written.

Running a binary at all also goes through a complex set of initialization steps a lot of programmers barely know exist, let alone are able to understand fully.

bandrami
1 replies
1d8h

Sure, but your choices are running an on-demand binary suid root, or running a persistent daemon as root.

Both have problems, but if you're going to switch users to root you have to do one of them.

dale_glass
0 replies
1d8h

The tool doesn't try to do away with root, it tries to do await with the setuid bit. Meaning, "running a persistent daemon as root" is the intentional solution, and presented as the significantly better option for good security.

NewJazz
0 replies
1d11h

Nope, but an instance of sshd only running on localhost could do the trick...

cesaref
6 replies
23h33m

Let's assume for a moment that it is lower risk than sudo (which is the problem is it addressing), why isn't it also called 'sudo', designed to behave the same as the thing it is replacing, so that anyone (and any scripts) that currently use sudo can carry on and be oblivious to the security benefits this new implementation offers?

I'd instead like to see a post saying something like 'on systemd based systems, a more secure implementation of sudo is provided', and all the clever whatever it is happens behind the scenes, and frankly i'll never need to know about it.

zzo38computer
1 replies
21h35m

Presumably because it uses different options and other different stuff, it has a different name. However, it might be useful to have a command "sudo" which emulates the options of sudo so that you can still use the same "sudo" command on systemd-based systems as well as on non-systemd-based systems. I don't really know how well that would work, though.

cesaref
0 replies
10h11m

Maybe you've not understood. I'm asking, why does it have different options? Is there a reason for that? If not, make it compatible, so a drop in replacement. Otherwise we're just spamming new commands at people, and the old sudo will probably end up living on alongside the new on systemd based systems just to keep scripts and the like working.

SkyMarshal
1 replies
19h34m

alias sudo="run0"

If run0 supports the same flags and parameters they'll be interchangeable with just an alias.

cesaref
0 replies
10h6m

I thought this was a security fix? Let's say I find a problem in ssh, I don't update it, call it 'newssh' and tell people to use an alias to point ssh to newssh do i? I just fix the app.

voiper1
0 replies
23h11m

calling it sudo would create the expectations that all the options, config, and usage is exactly the same.

It would appear that it's _functionally_ the same, but using a different mechanism and with a new name so they don't want to be locked down to all the other stuff.

agilob
0 replies
23h29m

Because there already is jq-go and jq-python. One of them is called jq in linux the other is called jq in MacOS. They are not compatible and you find out you're using the other one after 6 hours of screaming at the computer.

westmeal
5 replies
1d1h

what else is systemd going to eat :/

atoav
4 replies
1d1h

It would be really funny if systemd tried to replace pulseaudio.

figomore
1 replies
19h28m

Pulseaudio was created by Lennart Poettering.

atoav
0 replies
12h26m

Hence why it would be funny.

Narishma
1 replies
19h52m

pulseaudio is already in the process of being replaced by pipewire.

atoav
0 replies
12h25m

Jup and that is good. Finally sending audio to multiple devices isn't a pain anymore.

Iridescent_
5 replies
1d11h

Wasn't the recent liblzma attack already exploiting the fact that systemd has its hands in pretty much everything? Wouldn't this expand further the attack surface of systemd and the systems that connect with it?

viraptor
1 replies
1d11h

That's not a great summary of lzma. It was systems adding custom patch to ssh which used a systemd-related library which it didn't really need in the first place. It's a stack of issues that don't have much to do with systemd itself really.

But re. expanding the attack surface - unlikely. Systemd's primary purpose is to start processes with the right environment / permissions. systemd-run/run0 basically give you the tool to invoke that functionality with a terminal attached to it. That's smaller scope of extra code than sudo/doas deal with.

metta2uall
0 replies
14h28m

Isn't it a fault of systemd that libsystemd had a dependency on libxz? (because it implements too many things). It should have been possible to add the notification functionality using a tiny libsystemd-notify.

exe34
1 replies
1d11h

I'm surprised he hasn't started writing his own kernel by now.

jbverschoor
0 replies
1d10h

systemd operates the system :-)

SixDouble5321
0 replies
1d8h

I think this is bang on. Let's give it more surface area :/

StayTrue
4 replies
1d1h

Perhaps the nomenclature should be updated from GNU/Linux to GNU/systemd/Linux.

phone8675309
3 replies
1d1h

Until systemd consumes the kernel and then it will be GNU/systemd

CamouflagedKiwi
1 replies
1d1h

Or it consumes every other part of the GNU runtime and it becomes systemd/linux

Zuiii
0 replies
15h19m

At it's growth rate, it'll be just systemd. I'm only half joking unfortunately.

immibis
3 replies
1d3h

This will be great. We can finally deprecate sudo on systemd systems. Then we should be able to deprecate PAM, setuid bit, etc.

Retr0id
1 replies
1d1h

Is removing setuid actually a win? I know it presents a security risk, but it feels like we're not actually removing that attack surface, just moving it around.

NekkoDroid
0 replies
20h55m

Well... that "attack surface" isn't new, its mostly just repackaging systemd-run, which is just used to tell PID1 to launch a new process. So in total the attack surface would be reduced by removing sudo.

yjftsjthsd-h
0 replies
1d2h

I can see creating a system with zero setuid files, but I don't think this reduces PAM use, does it?

creshal
3 replies
1d12h

But they already ship pkexec together with systemd anyway via polkit, why are they again reinventing a wheel they already reinvented?

Unit files are a neat concept I don't want to miss again, but everything else done by Lennart seems to be an inceasingly stupid mistake born from hubris.

roenxi
0 replies
1d12h

AFAIK privileges are an area that has an easy problem statement ("execute this command with that capability") and is fiendishly difficult to execute in practice. `sudo` alone has weird bits to set in the filesystem, magic users and all sorts of unhelpful implications - and it doesn't even lead to any particular security for single-user systems. Same-user code is a scary enough place to be running untrusted code.

Those sort of problems sound like the sort that get a lot of attempts which run into the complexity wall and halt. I think Amazon has one of the best implementations of a privilege system I've used and it is horrible.

deng
0 replies
1d11h

Because pkexec has the same problems as sudo: it's a SUID binary. As Lennart says, the goal is to eventually get rid of SUID binaries altogether, as they are an inherent security risk. Replacing sudo with pkexec would not change much. In fact, pkexec has had its fair share of local root exploits over the past few years.

NewJazz
0 replies
1d11h

Not all distros ship pkexec with polkit. Polkit runs fine without pkexec present. This is kind of a non-suid alternative to pkexec. It's really more similar to a local-only ssh though.

andrewstuart
3 replies
1d12h

“Systemd” and “expand” used in the same sentence….. all the systemd haters will be triggered like it’s the national rifle association shooting carnival.

In many ways systemd has actually become the operating system. It’s so pervasive that it certainly is more deserving of naming rights than gnu. “Systemd/Linux” makes more sense than “gnu/Linux”

timetraveller26
1 replies
1d10h

"Systemd wants to expand to include a replacement of the Linux kernel" headline coming soon

Spivak
0 replies
5h16m

People have been memeing this for a long time but if you know anything about the project you would know that one of systemd's explicit goals is to use the full capabilities of the Linux kernel to hell if it's not portable to other kernels.

blackhaz
0 replies
1d11h

Mark my words, you won't be able to see the kernel anywhere in there soon!

CoolCold
3 replies
1d18h

Uses polkit.

run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY.

segasaturn
2 replies
1d3h

How hard would it be to create a program to send a signal to polkit "impersonating" run0 and obtains a root shell? :)

gh02t
0 replies
21h56m

Is that even a problem? Any program can shell out to sudo, hence why you shouldn't set NOPASSWD in sudoers. Polkit takes in a request on an unprivileged interface, that request is evaluated in privileged code against the set of privilege rules, and then passed the proper capabilities if the rules allow. This includes a mechanism where it can, if desired, prompt a user to enter a password etc to prevent a rogue program silently acquiring root. But even in the worst case, the rogue program is not going to acquire any capabilities that you would not otherwise have as with sudo, and the breakpoint between privileged and unprivileged code is (in theory) more tightly defined and controlled.

YtvwlD
0 replies
10h32m

You'd need to be root already, so hard.

withinboredom
2 replies
1d1h

I don't understand the point of creating an entirely new shell inheriting almost nothing. Seems like that would cause a lot of issues (i.e., sudo make install)

Arnavion
1 replies
1d1h

That's how sudo already works on most (all?) distros. Eg Debian 12 has:

    Defaults env_reset
... which will clear almost everything that `make install` would've used. OpenSUSE TW has:

    Defaults always_set_home
    Defaults env_reset
    Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"
... which is a lot more, but will still clear whatever `make install` would've used.

Anything you need to give to `make install` should be given explicitly, like `sudo make INSTALL_ROOT=$INSTALL_ROOT install` or whatever.

gcbirzan
0 replies
22h11m

If you're using autoconf/automake, you don't need to do that.

theshrike79
2 replies
11h20m

I think we're entering a point where GNU/Linux should be called Systemd/Linux

mrighele
1 replies
9h43m

That was the plan (by Redhat) all along, to have better control of the platform.

Spivak
0 replies
5h43m

To what end? It seems Redhat made a thing that solved a lot of their problems as distro maintainers and then made it OSS. This "control" doesn't really buy them anything.

segasaturn
2 replies
1d2h

I asked this in a thread about this from last night and didn't get a reply. For context, the way "run0" works is to apparently send a signal to polkit that requests a command under the root user's ID and permissions, thereby getting a privileged shell without SUID:

How hard would it be to create a program to send a signal to polkit "impersonating" run0 and obtain a root shell without entering a password?

Anybody know how this is being authenticated?

thayne
0 replies
23h57m

I would assume the authentication happens in polkit, so a fake client would only be able to run a command if it had the necessary credentials.

ongy
0 replies
1d1h

Without looking at the he specific implementation

There should be a service running as uid=0 that exposes an unprivileged API.

This service then takes the RPC and does authorization with polkit.

I.e. the unprivileged part doesn't talk to polkit directly. But a privileged part uses polkit instead of a custom sudoers style config.

nottorp
2 replies
11h2m

Yeah, Pottering's quest to overcomplicate Linux continues...

PublicSimple
1 replies
3h51m

It’s fitting he’s now at Microsoft. That’s the MS way.

nottorp
0 replies
3h14m

You don't say... reminds me of the Nokia dude... Elop was his name?

ivanjermakov
2 replies
19h32m

Offtop: long mastodon/X threads are so inconvenient that I would not even consider it a use case of such platforms. Write a blog post and link it there, ffs

kasabali
0 replies
19h19m

Sadly there's no "interaction" in blog posts

gnufx
2 replies
21h53m

In fact, if factotum were implemented on Unix along with an analogue to the Plan 9 capability device, venerable programs like su and login would no longer need to be installed ‘‘setuid root.’’ — https://plan9.io/sys/doc/auth.html

opless
1 replies
12h19m

Plan9port has factotum.

Plan9 has a completely different security model.

The Hostowner (usually Glenda) is essentially "root" and you're at the mercy of the filesystem regarding file privileges etc.

AFAIK there is no way to "become" glenda.

opless
0 replies
12h13m

In fact, according to sys/src/cmd/auth/login.c it looks like once you've logged it, you can shut the door using the capability device so then it's game over, no more hostowner for you

emmelaich
2 replies
14h31m

This is great!

There was (is?) a program developed by some debian developers that did a similar thing way back, but I can't remember it.

Anyone?

[edit - https://www.chiark.greenend.org.uk/~ian/userv/ is probably what I'm thinking of]

yonatan8070
1 replies
14h25m

I know of doas[1], but that appears to be an OpenBSD thing. Maybe Debian folks ported it?

[1] https://wiki.archlinux.org/title/Doas

rfmoz
0 replies
13h7m

hopefully

ece
2 replies
17h16m

Over the years I've switched from various cron daemons (anacron, cronie), sysloggers (r-syslog, syslog-ng), network managers (netifrc, NetworkManager) even ssh servers/clients (dropbear, openssh), and init systems (sysvinit, openrc) and never have I felt the need to switch to systemd despite reading some of Lennart's posts. I've used Gentoo over the years, maybe that's why.

Doas is available on Linux as a sudo alternative, I think I'll be trying that next, though I've only a limited amount of SUID binaries on my system to being with, and don't need sudo's extra features.

korhojoa
1 replies
15h18m

Now if then the commands run via some kind of privilege elevation mechanism would require pledges to be used, that would be awesome: https://news.ycombinator.com/item?id=38037075

"This needs root", okay. But you only get exactly what you need.

ece
0 replies
4h28m

It's not pledge, but firejail and other SUID binaries like it (bubblewrap, nsjail, etc..) are the only such ones on my system. It's better than grsec/chroot sandbox I used back in the day on Gentoo. I've also used shorewall, ufw, opensnitch for firewalls over the years. I could go on.

bandrami
1 replies
1d11h

Capabilities aren't guaranteed to be present, and in a lot of high-security situations aren't available (though obviously you could say that about sudo too)

bananskalhalk
0 replies
1d7h

Sounds exciting and might be obvious, but where will I find systemd and not capabilities?

tommiegannert
1 replies
23h4m

This is playing on the difference between hoping that sudo does the right thing juggling setuid and capabilities, and having a strict IPC boundary between privilege levels.

It sounds like a great use of systemd, for those who want to use it.

AshamedCaptain
0 replies
6h10m

There's like 3 components involved in making setuid safe (the kernel, the dynamic loader, and your exec), and at least one of them wasn't doing its job correctly (the dynamic loader). IPC by definition involves a superset of these components.

There's no reason to think that if you can't make a simple setuid binary safe, you can make IPC safe. IPC is an order of magnitude more involved. Specially because in order to gain any effective security you need a 3 way IPC (1st level = the client, which is completely untrusted; 2nd level = the request parser, which is trusted but runs without elevated permissions; 3rd level = the actual elevator process, which must run with elevated permissions).

throw0101b
1 replies
23h57m

First comment at the LWN:

[…] I think calling the flags "setuid" (as lwn appears to prefer?) just blurs things, since that's the name of a syscall (setuid()), which does something related, but is not actually involved in the concept that the inode SUID flag is about.

Hence, I am a bit confused what that comment here is supposed to achieve? It just creates confusion?

Lennart

* https://lwn.net/Articles/971747/

Reply by corbet:

Lennart, the purpose was to be sure that readers knew what the term meant in the quote, nothing more.

Never change, Lennart, never change…

thayne
1 replies
12h24m

First of all, I like the idea. But I have questions.

What does logging look like for this?

I don't think it would be too difficult to log commands run with polkit, but is there an equivalent of sudo I/O logs? My guess is there isn't now, but to fully replace sudo it will probably need a way to record everything on the ptty it creates.

What environment variables does it forward by default? From the man page it sounds like SHELL is. What about TERM? Any others? What environment variables are set? What is PATH set to?

How are signals handled? Will a signal sent to the run0 process be propagated to the priveleged process?

What about sudoedit? How would I achieve similar functionality with run0?

cl3misch
0 replies
12h1m

From the post:

well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist
YtvwlD
0 replies
10h31m

If this is the only bug, then this is easily solvable: create the pty in the daemon.

mise_en_place
1 replies
1d11h

sudo and su made sense when it was a multiuser time sharing system. You needed clear boundaries between each users of the system, and permission bits.

If I’m running on my workstation or desktop just let me run the damn thing. I don’t need an unprivileged user. On TempleOS you can modify the running system in ways you can’t on Linux.

foul
0 replies
1d10h

Plan9 propaganda in the wild

mise_en_place
1 replies
23h52m

This is just a complete disaster. Ever since libxz has shown how bloated and spaghetti code systemd is, now they want to make it seem like they're going to have "security" in mind. What a joke.

isatty
1 replies
3h14m

I wish systemd would die or just be just an init system. This whole thread is people suggesting vague and non obvious solutions to things that people already knew how to do with just linux utilities now with some weird other binary.

bananapub
0 replies
40m

what a bizarre point of view.

everything other than "being an init system" is a compile time option in systemd, so your complaint is that ... other people are building OSes and turning these things on?

which OS are you working on that provides all these convenient features and large-scale integration of software with them, with code that isn't in systemd?

Netch
1 replies
8h9m

A similar idea was tested in an experimental BSD clone in Berkeley in mid-1980s. (Great sorry I havenʼt kept link to the description, so rephrase with my own words. Maybe this was in the McKusickʼs book?)

No suid or sgid was allowed. A daemon started from init and listening on a socket listened for connections, checked permissions and run the specified binary with requested permissions. A caller had to interact with the started program using pipes.

It seems the complexity of passing all to pipes was why the approach was rejected. Instead, the checking of inherited environment was strengthened. "Everything new is well forgotten old."

lyu07282
0 replies
4h3m

44 years and ~20 local privilege escalation vulnerabilities later...

KaiserPro
1 replies
1d10h

Thats fine, and lord knows we probably need a replacement to sudo.

However, sudo needs to be user friendly and fail safe with decent information as to why its failed. Something that service files historically didn't do.

But, the way it's supported also needs to change, it almost certainly needs to be decoupled from systemd's release cycle.

I hope that we have all learnt from early systemd, and that we all won't take a "lets piss on each other's chips" approach. I'm too old you you lot to start flame warring over stuff you'll never actually fucking use.

mynameisnoone
0 replies
20h6m

doas exists but isn't universally available but already solves this problem. sudo has too many features and permits excessive configuration, but it also has the convenience of ubiquity. Inventing a third thing tied to systemd is absurd and unnecessary.

ykonstant
0 replies
12h41m

Is there a way to read this sequence of messages as a coherent whole in the correct order?

viraptor
0 replies
1d12h

That looks pretty good. I'm glad that the plan is to make this more typing friendly - systemd-run is not good enough for daily usage.

sys_64738
0 replies
1d4h

How long before humans are systemd compatible?

slackfan
0 replies
22h49m

Nope. I trust this about as far as I can throw it, and I will continue editing my own files.

If I want NT, I'll just run an NT-based OS, thanks.

segasaturn
0 replies
1d3h

This is very interesting, can somebody explain what this is and how it's different from executing through sudo? The LWN post links back to Lennart's Mastodon which in turn is a big pile of toots (ugh) in the wrong order

rurban
0 replies
1d11h

For one, a good effort by Lennart.

rmbyrro
0 replies
6h2m

Why use a short-form message social network to publish a blog post?

righthand
0 replies
18h40m

The big switch to systemd was always a mistake and this announcement just proves it.

pkulak
0 replies
14h57m

But can I symlink sudo instead of run0? There are so many scripts that assume sudo, not to mention my own fingers.

orzi
0 replies
15h31m

Mother: We already have sudo at home

HN: But, Mom!

nan60
0 replies
23h0m

Guess it’s time for me to switch to Void…

mehdix
0 replies
1d10h

Lennart's toots suggest they are replacing a complex SUID binary with an already existing component (systemd-run) with better workflow (service manager handling the elevated context), which sounds like a sane move to me.

kristjank
0 replies
1d12h

I am looking forward to the day systemd will implement everything a typical Linux system needs. No more systems greater than the sum of their parts, just a Half-Life 2-style Combine of Microsoft sponsored Poetteringware, running a monolythic system on top of a monolythic kernel, until systemd rewrites the Linux kernel as well. The future is bright! \s

Seriously though, this seems to be a decent replacement for sudo if it works as seamlessly as it's described in the article. I still prefer the doas line of approach that simplifies the tool as much as possible, but I see the value of having such an important tool integrated into the existing system tooling, especially if it already includes everything but the kitchen sink.

kingspact
0 replies
18h8m

Linux is dead lol.

jmclnx
0 replies
23h53m

Why ? I guess you do not get this unless you have systemd, that is fine by me. If I would use anything outside of sudo I would go to doas.

My home distro does not have systemd, so I guess I may never see run0.

I have been evaluating the various BSDs for a few years in case my distro is forced to use systemd and friends. The distro I use is fighting the good fight against large monolithic tools, but it is having a hard time trying to avoid these monolithic tools.

With Linux slowly forcing systemd, Wayland, various Desktop Environments and now this, my move to a BSD may happen sooner that later.

Curious, I wonder how close run0 is to how Windows raise auths ? With LP now working for Microsoft, is he cloning tools from Windows for use in Linux ?

j16sdiz
0 replies
11h41m

Oh, great. Adding another moving parts via IPC to essential system tool. Sure this would make recovery/rescue scenario more "fun".

hello_computer
0 replies
6h22m

fix pulseaudio and then we can talk.

gpderetta
0 replies
1d10h

Does systemd read email yet?

gigatexal
0 replies
19h26m

I’m here for it. I like systemd for the most part. I don’t care for this red window tinting tho.

frafra
0 replies
1d10h

This is not new functionality:

"There’s a new tool in systemd, called “run0”. Or actually, it’s not a new tool, it’s actually the long-existing tool “systemd-run”, but when invoked under the “run0” name (via a symlink)".

systemd-run is very useful to run tasks with specific cgroups settings, or at a specific time. It asks for password whenever needed.

constantcrying
0 replies
10h2m

But enough about all that security blabla. The tool is also a lot more fun to use than sudo. For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven't given up the privileges yet, and marks the output of all commands that ran with privileges appropriately.

WHAT AM I READING?? Why can't the systemd developers just be normal?

I also suspect that this will interact terribly with anyone who uses a certain kind of terminal theme. Do they not know that you can have these "nice to have" features, off by default, so that anyone who wants can enable them and anyone else is never bothered by them?

chillfox
0 replies
3h16m

I am really not looking forward to systemd taking over another part of the system with how unpolished and flaky their replacements usually are.

Anyway, I have been using doas instead of sudo for a while on servers, it’s rock solid if you don’t need some of the more advanced features of sudo.

broknbottle
0 replies
21h50m

sudo machinectl shell "${username}"@

sudo /usr/bin/systemd-run --machine="${username}"@ --quiet --user --collect --pipe --wait "${command}"

bhaney
0 replies
23h38m

Is it "run-zero" or "run-oh"?

anonymous_union
0 replies
23h21m

holy shit this guy knows no shame

adontz
0 replies
1d12h

here's a new tool in systemd, called "run0". Or actually, it's not a new tool, it's actually the long existing tool "systemd-run", but when invoked under the "run0" name (via a symlink) it behaves a lot like a sudo clone.

TacticalCoder
0 replies
1d18h

Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, ...

Of course. The solution to every Linux "problem" is, of fucking course, to have the PID1 spread is tentacles to yet more part of Linux.

Every single problem can be solved by giving yet more power to PID1... Except the problem of PID1 having too much power.

DeathArrow
0 replies
12h30m

Someday systemd will going to replace Linux entirely.