What you're refering to as Linux, is in fact, Systemd/Linux, or as I've recently taken to calling it, Systemd + Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning Systemd system made useful by the Systemd corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX
π€£
Thanks to BSDs we have sane alternatives :)
Oh it's no longer POSIX, he's seen to that!
ProgrammersAreHumanToo, great stuff.
When does systemd stop? Linux without it is increasingly looking unlikely in the future. Are we not worried about it being a single point of failure and attack vector?
This isn't a moan about the unix philosophy btw, but a genuine curiosity about how we split responsibilities in todays linux environment.
SystemD will consume the entirety of Linux, bit by bit.
In 2032, SystemD announces they're going to be introducing a new way to manage software on Linux
In 2035, SystemD will announce they're making a display system to replace the ageing Wayland
In 2038, the SystemD team announces they're making their own desktop environment
In 2039 SystemD's codebase has grown to sixteen times its size in the 2020s. SystemD's announces they're going to release replacements for most other packages and ship their own vanilla distro.
In 2045 SystemD's distro has become the standard Linux distribution. Most other distros have quietly faded away.
In 2047, SystemD announces they're going to incorporate most of GNU into SystemD. Outrage ensues from the Free Software Foundation, which vehemently opposes this move.
In 2048, Richard Stallman dies of a heart attack after attempting to clone SystemD's git repo. SystemD engages in a hostile takeover and all resistance within the FSF crumbles
In 2050, SystemD buys the struggling RedHat from IBM for $61 million.
In 2053, most world governments have been pressured into using SystemD.
In 2054, Linus Torvalds, fearing for his life, begins negotiations to merge kernel development into SystemD
In 2056, the final message on the Linux kernel development mailing list is sent.
In 2058, Torvalds dies under suspicious circumstances after his brand-new laptop battery explodes.
In 2060, SystemD agents assassinate the CEO of Microsoft.
In 2063, after immense pressure from SystemD-controlled human rights organisations, Arch developers discontinue development.
In 2064, the remaining living Debian developers release the next stable version of their clandestine and highly illegal distro.
I think you might want to recheck the ages of some of the people in your timeline, most of them aren't that young anymore.
Yes, because it's easier to take care of octogenarians than people who might actually put up a fight to having their laptop batteries replaced with a pipe bomb.
Debian already uses systemd.
Debian in many ways isn't as slow-moving as people think.
For example, they moved to Wayland by default (for Gnome anyway) in 2019. A number of well-known distros likely won't have that until 2025/2026 or beyond.
Sadly they've been dropping archs throughout the years, meaning they're no longer the distro you can use to run on "anything" from a pi to a mainframe...
Doesn't trixie still support like a dozen arches? I think one of the more recent deprecations was MIPS BE which is functionally obsolete in 2024, at least insofar as practically no one is using it to run a modern distribution.
Bookworm, Trixie, and Sid all currently support a total of 10 different architectures.
And looking through the Wikipedia article for Debian's version history, most of the dropped architectures were functionally obsolete when they were dropped, or like the Motorola 68000, when support was added. (notable exceptions being IA-64 which was dropped 4 years before intel discontinued it, SPARC which is still supported by Oracle, and PowerPC.)
If your bar is "modern distribution" stick to Ubuntu.
If you want to maintain older hardware Debian used to be a go-to solution.
What's the go-to solution now?
Most likely LFS or some tailored distro I haven't heard of.
Probably the weirdest joke comment I've ever read.
Thanks for that write up. Made my day! π
That comment was brought to you by an AI LLM. No one actually took the time to write that.
Nope, doesn't have any of the hallmarks of an LLM and LLMs aren't yet clever enough to produce original humor like that.
π₯΄
This is a script of Simpsons episode and Torvalds will actually die in 2058.
Dude if you made a movie or novel about this that would be awesome
One way to notice a person has "systemd derangement syndrome" is by looking at how they write systemd: if they write it SystemD they are already in late stages of SDS and it isn't curable anymore.
Either that, or it's a joke.
When does systemd stop?
"systemd announces a repleacement module for the kernel"
HurD
By this logic the Linux kernel is also a single point of failure and attack vector.
sudo isn't going away, so does doas.
run0 is just another alternative to use or not.
There are still distribution out there without systemd and if there ever won't be any systemd-free distributions left and systemd would become a critical part of the Linux ecosystem, then it would get the same treatment as the Linux kernel with many professional maintainers.
plus, it isn't like this isn't exactly like adding another "door" to the "systemd building". It's a modular component of systemd, so more akin to replacing the sudo building with a new, but still separate, systemd sudo building
@Olap
I agree. As someone who uses systemd on daily basis (I use Arch, BTW π) I really like it, but I am a bit worried about it being a single point of attack. Maybe just push doas as default instead? I never used doas but I watched few videos about it, so I guess it's fine and probably better than sudo (less bloated).
Just my few cents.
I don't see how something would be inherently easier to attack if it is called systemd-foo instead of just foo. Attack surface and vectors do not depend on which project develops a particular tool.
I'd be willing to bet it's people fearing another xz-like situation
Gentoo, Slackware and Devuan can be used without svchost for linux.
They'll only stop when they rebrand it to systemd OS.
Gentoo, Slackware and Devuan can be used without svchost for linux.
Debian works fine without systemd too, there's a page on the wiki on how to install without it, or remove it after the fact.
Easy with sudo apt remove --purge --allow-remove-essential --auto-remove systemd:
:-D Time to go outside.
A lot of debs add services to systemd, do those just skip that part?
They seem to. Debian explicitly supports multiple init systems, sysvinit being the primary alternative, so packages have to handle systemd-init not being there.
Systemd is a bit of a hassle to be rid off, but thankfully it's not actually that hard, the hardest part I found was converting systemd services to whatever init system I use.
I wonder how many hours you sunk into that practicality-free, weird-philosopy-dependent project
Probably not much time, a lot of packages come with init scripts anyway, and they're pretty trivial to write if not.
You can certainly argue it's a philosophical choice, I'd say it's more down to recognising the many poor architectural choices in systemd, rubbing agaist its many pain points and misfeatures and being alarmed at the size of the attack surface it exposes. I understand there is an effort underway to reduce the size and complexity of the main shared library to help address the last point, but just the fact that is necessary shows the scope of the problem.
Systemd is fine. If it wasn't, most distros wouldn't have switched to it years ago.
Let's agree to disagree on that point. Redhat switched because they invented it, and so took all the RHEL derivative distros with them. Debian switched to prefer it after a rather contentious vote and so took all the Debian derivative distros, including Ubuntu, with them. That just leaves a lot of the smaller distros, most of which seem to have stuck with sysvinit or similar as far as I can see.
The arguments against systemd are very unconvincing but more importantly, there is zero evidence that they actually matter.
And it works.
Further, in order to represent this as a nearly unilateral decision you failed to mention that arch, centos, and opensuse all opted in independently.
And no offense but angry Internet randos arguing software philosophy will never convince me to disagree with the creator of the Linux kernel.
Linus Torvalds said:
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
I obviously find the arguments against systemd more persuasive than you do, and that's fine, it's all open source and we can all make our own choices about it. My experience with it over the years has been, and still is that it vastly over complicates things that used to be simple, often the less commonly used parts just don't work right (the automounter is a particular bugbear of mine, and few distros seem to use the network management component). The arguments do matter in practical terms as they directly impact how it works.
Of the distros you mentioned, centos is a RHEL derivative and so wasn't independent, arch packages multiple init systems, but yes, I'd forgotten opensuse, and they seem to be firmly in the systemd camp.
I may be an internet rando, but I'm not actually angry, more just disappointed. I'd agree with Mr Torvald's opinion that some of the design details are insane, but I think they are more fundamental than just 'details' as many are to do with the fundamental concepts around what systemd is and how it works. Linus can be a real dragon around changes to the kernel, but he's always tended to be more relaxed about the layers above it.
That the developers of systemd are 'much too cavalier about bugs and compatibility' is surely clear to anyone who follows the relevant mailing lists and bug trackers, and should alarm everyone.
That quote carries the opposite connotation of what you seem to take from it. He's saying despite having issues with the devs, he acknowledges those issues probably don't matter.
I admit I don't understand the internals of any of these systems. But I do understand that if the creator of the kernel isn't concerned about systemd, and that if the vast majority of distros use systemd, then it indeed works well enough. The systemd apocalypse never happened and likely never would happen.
I see this argument as software conservatism. The rest of us will be okay with the thousands of knowledgeable developers that seem to think systemd works just fine.
I'm not disputing that he doesn't think the issues are major, as I said, he's usually pretty ambivalent about what runs on the kernel, so they're not issues he cares about. On the flip side, I do care what is running because I have to manage and support it.
I do wonder if we're talking at cross purposes though. You seem to mostly be talking about the systemd init system, I'm mostly talking about all the other bits it, as a sort of umbrella project, tries to encompass. I don't much like the init system, I prefer to be able to explicitly set the ordering of the steps, rather than having them inferred, and I prefer shell script that I can test to unit files, but it mostly works ok. So does every other init system though, so it's not a selling point.
As I said, the big problem is around how they've tried to do everything, much of it less well than what they're replacing. Yes, you can build a system that uses systemd-init and none of the other components, but that still drags in a load of other dependencies, so you might as well use a different init that's smaller and cleaner.
We came close to the 'systemd apocalypse' recently, when distros hooked the systemd library into openssh without understanding just how bloated it is and how many poorly monitored dependencies it brought in. It was just luck that the right person spotted a slight change in timing and investigated.
Ultimately I suppose it comes down to the level you interact with your systems at. If you just want to install your OS, a few packages they directly support and let it get on with it, then you probably neither know nor care that you run systemd, and that's great. On the other hand, in my experience, when you try to push the system past that and do anything more customized you start running into the sharp edges and misfeatures on the various systemd components.
took me about an hour to get started with artix originally, and maybe a couple more to really familiarize myself with the init. As for practicallity, it's been a large improvement for me.
Soon we will have to call it GNU/systemd/Linux
Nah. Replacing the kernel is probably planned for the next point release - it'll just be GNU/systemd
Can we rename it GNUtriSystemD?
I mean it should kind of already be something like GNU/SystemD/X11/PipeWire/Linux, I guess.
It's not like the GNU utils are the only massive integral part of the OS. I think GNU/Linux caught on squarely because many people follow Stallman, and that's how he wants people to refer to it.
It definitely made way more sense at early on. I mean GNU made most of UX of using Linux at some point. Systemd, and the browser now make a much bigger portion than before, and the world is more than GNOME now too.
Systemd makes life easy. It also makes Linux more teachable. I like accessibility and donβt even mind this
hard disagree. life with plain text logs and daemon init scripts was so easy and nice. But we can't have nice things...
Those hacked together system-specific bash scripts were shit. Having a standard way of creating, starting, ensuring restarts,and logging services is so much better.
You can still get all the plain text logs you like.
Those hacked together system-specific bash scripts were shit.
With a different feature set per script as well. The systemd service files have often been pushed upstream.
Pretty sure people liking those scripts never really tried dealing with them across distributions. Though this just rehashes things that were said when distributions decided if to switch to systemd. Still the same strange claim that those scripts are somehow easier. It wasn't, it is also way easier to package a systemd file from upstream than to maintain that stuff within a distribution.
How do you get plain-text logs instead of the garbage binary format that journalctl forces on you?
Set ForwardToSyslog=yes in journald.conf and install a syslog daemon. Also optionally Storage=volatile (I wouldn't set Storage=none unless you want systemd to no longer show you any logs anywhere including in systemctl status because I assume it will do that)
Thank you!
Definitely reads like a Microsoft answer, seems so much easier than just reading text
By configuring journald to forward messages to syslog as is the default.
"forces on you" π
Edit: Systemd has been around for 14 years. Did you never think to google this?
It's not the default fwiw. From journald.conf(5):
By default, only forwarding to wall is enabled.
You know what's nice? Being able to sit down at any Linux distro and being able to set up and configure services without Googling how to use that particular distro's init system.
But it's so unbearably slow.
Me when my computer that has a typical uptime of 37 days boots up in 7 seconds with systemd instead of 5.5 seconds with runit: π‘π‘π‘π‘
Lmao yeah exactly
I'm not on the systemd hate train by any means, but I don't understand how this is any improvement over pkexec
I donβt understand how this is any improvement over pkexec
That has the same problem as sudo: the SUID bit is set for it.
The fact that run0 uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone can systemctl status, but systemctl reboot needs to be in the wheel group) which is why its generally used within systemd already. And it wouldn't surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.
I'm unclear from the documentation, does pkexec work under non-GUI contexts?
As long as you have polkit setup to work in terminal sessions, yes. This is pretty standard these days, though not particularly widely used.
Or as I've taken to calling it, GNU+systemd+Linux.
Not that I'm opposed to a better sudo alternatives, but I find it rather ironic that one of the reason stated is the large attack surface, considering systemd is a massive attack surface already.
This isn't exactly a "new" attack surface, so removing the attack surface that sudo (and alternatives) is, is probably a net positive.
That attack surface is not vanishing. It's would be relocating the same attack surface to something that might have an xz library in memory.
The attack surface is there either way, this is just functionality repackaged that existed already before (systemd-run, which is calling into PID1)
all compression libraries (actually most libraries at this point) are dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)
As Microsoft and Poettering intended.
feature creep
I'm no Linux expert, but I've never had any problems with sudo, it just works. Shouldn't systemd have higher priorities on their mind? This feels like change for the sake of change. And if this does happen, I sincerely hope that it just works, like sudo.
I think the article (or more Lennart Poertting post) explains it quite nicely. The problem with sudo is that the sudo binary itself has the ability to gane elevated privileges which is a potential attack surface
There's a rewrite of sudo happening in rust, but he wants to throw out the SUID idea altogether?
when invoked under the βrun0β name (via a symlink) it behaves a lot like a sudo clone. 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. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY.
That sounds like opening up the door to what windows is doing UAC and the wonderful vulnerability that the GOG Launcher had for privilege escalation.
I'm not a security researcher, but giving arbitrary users the ability to tel PID 1 to run a binary of the user's choosing is... probably not what Pottering is suggesting, but opens up to such vulnerabilities. And if it's written in C/C++ my trust is further reduced.
Giving users access to PID1 running binaries, giving users access to the kernel running binaries as root, I don't see much difference. SUID was notorious in the past for being leaky, it only ended when distros got serious about fencing use of it in, giving it only to programs actually needing it, making sure that they drop privilege properly, etc.
If anything I'm in the PID1 camp because it's more microkernely. But in any case broader userspace shouldn't really care about the mechanism, only have an API to do it and that API being a bit in the file permissions is soooo 1960s.
And if itβs written in C/C++ my trust is further reduced.
Do you trust Linux? Because if so, have I got news for you.
Wait until they hear the language used to implement OpenBSD. Imagine being one of the authors of seL4 encountering a member of the rust cult.
Oh, it's gonna use polkit. Sudo bloat is a grain of sand compared to polkit.
Why people want to replace sudo with polkit? Visudo is no near as obscure as configuring polkit.
I hope distro maintainers don't follow this.
...is pkexec not good enough already as a polkit based sudo replacement? Why would one need to systemd-ify that?
I just treat polkit as "set it and forget" kind of thing and leave it on defaults, I'd rather spend my time on something more important
They can't help themselves. They gorge themselves on his phallic offerings.
First thing I do with any new desktop installation is disable polkit prompts.
Fuck having to enter my password every time I want to do something.
Hey uh can I get your IP address real quick? I have a strong suspicion your philosophy extends to your network ports.
You'd be wrong about that.
Edit: he just downvotes me instead of admitting he's wrong about his assumption, lol.
sudo is already an optional component (yes, reallyβI don't have it installed). Don't want its attack surface? You can stick with su and its attack surface instead. Either is going to be smaller than systemd's.
systemd's feature creep is only surpassed by that of emacs.
systemd's feature creep is only surpassed by that of emacs.
Tomorrow's headline: emacs wants to expand to include a Sudo replacement
And after that: emacs wants to include a systemd replacement
:wq
I'd take that over systemd.
But systemd is modular. They make an offer and distro maintainers and admins get to choose which parts to use
The problem is that those modules are packaged by the developers as opt-out rather than opt-in. It's a variation on Microsoft's old embrace-extend-extinguish playbook, only the "extinguish" part hasn't worked so well because there are some stubborn distros whose needs don't align with what systemd provides and have maintainers that go out of their way to provide alternatives.
(By contrast, although we may joke about emacs, it's the myriad of third-party extensions that cause it to just about be its own operating systemβit doesn't all ship with the core.)
Or you can use a doas implementation like OpenDoas, or maybe sudo-rs...
Though a Rust clone of sudo that operates in the same way will still have the same problems.
And there's also doas which is a nice substitute.
I'm not a fan of having root be able to actually login.
Even more so in a true multiuser env where I would rather have privilege escalation be more granular (certain user/groups can esculate certain actions but not others, maybe even limit options of a cmd).
Granted, in a true multiuser environment with an admin who's carefully tailoring /etc/sudoers to make sure everyone has the least possible privileges that will allow them to still do what they need, sudo is more secure. There's no doubt of that.
On a machine that has only one human user who's also the admin, and retains the default sudo-with-user-passwords configuration, su vs sudo is pretty much a wash, security-wise. su requires a second password to get root access, but sudo times out and requires the password to be re-entered while a shell created by su can stay open indefinitely. Which is more easily broken will depend on other details of your situation.
(If you're running an incorrectly configured ssh server that allows direct root login with only password authentification, having a root password could contribute to problems, but the correct fix there is to reconfigure the ssh server not to do something so stupid. I hope there's no distro that still ships that way out of the box.)
A lot (and I mean a lot) of criticism can be leveled at systemD. One of the upsides of it becoming popular is the standardization of much of things from the developers' perspective. It's easier to target multiple distros when you can rely on systemD's single implementation of the feature. Over the next decade, I forsee systemD eating more and more of the userspace, until you are only left with managing the differences between DEs and which display server they are using. We're already headed towards immutable base systems with apps shipping with their own dependencies, which we reduce the differences between distros even further.
until you are only left with managing the differences between DEs
Maybe they'll add a DE as well?
Just kidding!
systemde
SystemDE
Don't give them ideas π
If Canonical and RedHat weren't backing different horses (Snap vs Flatpak), I could see the app containerization system coming under systemD as well fairly soon. The Cosmic DE project uses functionality from systemD to overlay changes onto the system that are reversible, so that alpha versions of Cosmic can be tested without permanently changing the base system. Imagine apps shipping on whatever container runtime, and dynamically overlaying system-level changes as needed for things that tap into the host system via systemd-sysext.
gross!
This is great. Not having the attack surface of sudo (and not even being a SUID binary) certainly are great additions.
And I hope people realize that systemd is not one large thing, but a (large) collection of tools.
The attack surface will be a systemd daemon running with UID=0 instead, because how else are you going to hand out root privileges?
So it doesn't really change anything to the attack surface, it just moves it to a different location.
That already exists. systemd-run is already available today. So the attack surface would be smaller
Not really, because you're now going to make it do more, i.e. incorporate the functionality of sudo and expose it to user input. So unless you can prove that the newly written code is somehow inherently more secure than sudo's existing code, the attack surface is exactly the same.
thatΒ systemdΒ is not one large thing, but a (large)Β collectionΒ of tools.
Who don't work without Systemd. And Systemd can't coexist with tools in the same repo doing the same job in a portable way.
I think Chimera was it (?) which tried to have Systemd and Runit and others in the same repo. With lots of wrappers and shims. Not because of Runit & co.
Just like gnu utils.
But gnu utils work on BSD and others, while Systemd is Linux only.
Right. That reminds of the time I was visiting a friend who had broken his Linux computer (No, not "apt-get remove --purge systemd" but they did something slightly similar). When I booted from a live Linux, used chroot and wanted to use configure networking : FAIL because systemd was ... not running. As he had no Internet because of his broken machine this caused some delays in fixing this but we got the job done eventually.
This is great. Not having the attack surface of sudo (and not even being a SUID binary) certainly are great additions.
And I hope people realize that systemd is not one large thing, but a (large) collection of tools.
XZ-utils rings a bell ? It was among others Debian wanting to pull in part of a systemd tool into openssh and that almost turned into a world wide disaster :(
I didnt understand that sentence. Is that what you meant?
Among other things, Debian wanted to integrate a part of the systemd tools into openssh, which almost led to a worldwide catastrophe
xz is not part of systemd or openssh afaik.
You didn't follow the XZ-utils story ? The malicious actor worked for years on that XZ backdoor that targeted the fact that some Linux distributions were modifying their openssh package to enable systemd notifications.
Ok true, it was a systemd dependent issue. But it only makes sense to have those notifications. The problem is dependency on small hardly maintained products, which systemd will improve by centralizing it.
And where do maintainers for the new parts of systemd come from? The larger systemd grows the more parts of it will be neglected. Also in regard to people checking commits, opening up doors for exploits like the one in xz.
I dont know but for sure has pros and cons
But it only makes sense to have those notifications.
Maybe in your mind it makes sense. Going for ease of use rather than security is not something that OpenBSD would quickly do. If you read some more about what "jwz" has to say about all the screensaver bugs in Linux, like here : https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition and realize what a mess that Linux maintainers are making again and again, and then have a look at Debian and their packaging of xscreensaver. Guess what ? Debian added some systemd thingie to xscreensaver. π€―
I like Debian since a long time and I use it. But the tinkering of Debian package maintainers and always wanting to do things the Debian way is not something I am always very pleased with. Remember the OpenSSL Debian fiasco ? That shows a problem with Debian which may still exist. Too many packages, not enough maintainers with enough spare time, and no coherent team work of a security team.
You are talking about Debian holding back random packages for stability. This is of course not very cool but it needs to be tested.
I am very much in favor of isolate app environments controlled by upstream devs, containerized and with a permission system. The system is made by the distro, and can be stable and very tested, and the apps are simply isolated and made by upstream.
There is no xscreensaver on Wayland and I think this will not come back?
Kinda feels like writing a script that implements the sudo CLI but calls pkexec would be an easier way to do it. Given that so many systems already come with both sudo and pkexec, do we really need yet another option?
The point of this is to implement some form of privilege escalation without the SUID mechanism. sudo, pkexec and doas are all SUID.
I've had to scroll down eight pages to find a post that seems to actually address the good points raised in the article.
I honestly started out not liking systemd at all, mostly due to the reports that it did waaay to much, but nowadays, I like the concept.
It is basically officially moving daemon management from a script-based approach to a table/database-based approach. That improves static analyzability, therefore increasing clarity, and probably even performance.
I agree that we should abandon scripts and move towards declarative software management, and abandoning sudo for a more declarative system seems like a good step to me.
So I don't even use systemd myself I run OpenRC. Yet honestly I find the idea quite intriguing, having the service manager (PID 1) invoke the command seems like a cool idea to me.
It's not really a sudo alternative as much as it is another way of doing something similar.
How does systemd-run/run0 handle what /etc/sudoers currently does?
I'm disappointed in how little technical discussion there is in this thread.
Looking at the implementation, it doesn't really implement sudoers or tools like sudoedit in any way. systemd-run has already been an existing tool for quite some time and this is really just a different CLI for it. That tool asks systemd to make a temporary new service and immediately run it. That, in turn, requires blanket yes/no approval for org.freedesktop.systemd1.manage-units via polkit.
So with run0, you can either do everything or you can do nothing. In-betweens are just not a thing at the moment. There's very little new backend code running as root.
run0 bash should behave very similar to something like systemd-run --uid=0 --gid=0 --wait --same-dir --send-sighup --pty --pipe --collect bash and the majority of those options have been available for quite a while.
Idk
Systemd has always been about "don't ask questions or well call you obstructionist and old".
sudo is overkill for most users tbh
so is systemd
Actually no. The thing is just that systemd handles so many things that makes the lives both developers/distro maintainers and users easier, but most of it happens in the background. You can forget about having to learning complexer tools, just do it all via systemd
Yeah I think I'm the exception but I just use su at home
Surprised people aren't moaning about systemd being too big already and still wanting to do more.
It's too big!
π
That's what somethin' somethin' said lastnight, Trebek! ;)
SPoF !!!! Ahhhhh we all dead
The comments are here now, you can come check again π
π
Systemdeez nuts
Gentleman and scholar
The meme is becoming a reality. Systemd really is going to try to be everything lmao
AlwaysHasBeen.jpg
But for why (I'm commenting this before reading) wouldn't it make more sense to home I'm the scope of systemd so it can be easier to maintain? Why have it do everything?
systemd is more of a set of products and software components branded under a single name rather than a single thing.
systemd itself is rather simple, as most other pieces systemd-* software, like systemd-boot, systemd-networkd and systemd-resolvd. these are usually more stable and less bloated than more popular alternatives
As long as they can work independently, yes. If they are modular and a distro admin (or just a computer admin) can choose to install and use systemd-x but not install or use systemd-y, we are in good business
Now if you have to take a few you don't like or need to use so that the one component you do want works, then no
I honestly don't know enough of systemd to say either way
Most of systemd stuff is decoupled well. You don't need to use networkd to make use of resolved for example.
Good to know, thanks for the answer
Oh okay I didn't know that thanks
You can't think of it a single massive project. It's actually lots of small components.
We could argue the linux kernel is bloated too. The reality is though, provided the project is designed to be modular (as SystemD is), it actually makes sense to keep it together, to ensure there is a standard base and all the components are synchronised fully with their API's.
It also saves distro's a lot of effort.
distro's
You can pluralize without the apostrophe. In fact, you never need an apostrophe to pluralize.
It also saves distro's a lot of effort.
Only if they want to break free.
And they don't need nfsroot or a separate consolidated /usr mount or, really, a whole host of things that lennart didnt understand and unilaterally broke like an arrogant noob.
But that's blasphemy.
In practice, all those tight coupling between components mean that it behaves more or less monolithic, despite the claims to the contrary. Replacing them with alternatives is a pain because something else breaks or some software has a hard dependency on it.
Oooh okay that makes more sense. Thanks I didn't know that
I can understand that it makes it easier to add changes that would benefit systemd and distros in general. I read that they introduced run0 to solve long shortcomings of sudo (I'm not aware of which). That sounds logical.
Why have it do everything?
Isn't the guy behind systemd a (former?) Microsoft employee? I feel as though that might offer a clue as to why the trajectory towards bloat.
He's working for Microsoft now but it's very recent, he developed systemd while working at RedHat.
I don't even know of he's still working on it. There are a lot of things to be said about systemd and Lennart but the link to Microsoft is irrelevant.
It is. He is poisoning Linux, slowly, from the inside. Like the XZ attack, just smarter and much slower.
The guy who discovered the xz attack was also a Microsoft employee, for what it's worth.
Maybe they discovered xz attack because they are familiar with these things.
Why do you consider it as poisoning? I've heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?
Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they're a very welcomed feature imo
By itself, solely doing init, it would have been fine, however, binary logging (even if you eventually end up with a text log, that's wasting disk space on a binary format no one wants or needs), and it didn't stop there. He keeps replacing Linux subsystem after subsystem, and many of those replacements are not progress, just duplication of effort and creates more ways for configuration drift.
Here is the rationale for the Journal. In short it is really not that simple and it has a lot of advantages over simple text files and it saves disk space.
Having the logs twice is saving space, got it. Do you hear yourself?
You can still forward to text syslog or to a central logging server like Loki if working with multiple hosts. I still don't get the issue with binary logs.
Yes, and many distros have that out of the box... But they don't have it sent to keep the binary journal as close to empty as possible. So you end up with twice the space in use for logs. As for the issue with binary logs, text logs can be read by far more tools and utilities, rather than just journalctl and pipes.
You can set the space limit for journals logs really low then, to avoid double space usage. As for the last argument, that also was an issue for me years ago because not all tools were compatible with the journald format, but that's since long fixed now and I've not experienced any issue for a long time. Journal logs provide a standard format for all applications, so third party tools don't need to be compatible with every log format of your applications. And it also comes with great additional features like -b or --since etc. So I still don't get the issue here
The issue is logs are suppose to be text. Seriously, wtf. You some Poettering fan boy or something?
I was arguing how it is a very useful tool with many great additions, rather than rely on the: "no old better!" reply based on ignorance. But it looks like your replies have turned full removed, so no point in continuing here to try and educate you.
Text is compatible with all the grep, awk, sed, text editors, what have you. As for the argument of it binary saving space, not on modern filesystems with compression, like zfs, btrfs, and bcachefs. The entire resistance against tampering is bogus, any systems where that is a concern already live scrape logs to an off server indexing service. If you are concerned about poorly formatted logs, that is an application configuration issue. Address it directly with the application. There are no benefits to a binary log, especially when journalctl is absolutely no faster at jumping to the end of the long log than standard less is. Poettering has you chasing phantoms. He always does. He's like the politician who justifies horrible bills by saying it's to protect the children.
Well... Poettering will eventually work his way up to browser engines and then we'll get something efficient... Here's the announcement:
"There's a new component in systemd, called "engined". Or actually, it's not a new component, it's actually the long existing "WebKit" engine now done properly. The engine is also a lot more fun to use than "WebKit" or "Blink" because you can finally have hundreds of tabs open in your browser without running out of RAM.
Coming soon in Coming for systemd 981.
I'm not surprised. Not surprised at all. (scope creep)
new sudo vulnerabilities? how exciting!
E: read the article, I guess that is part of the reason for the proposal. interesting
Even when that releases, it doesn't mean distros will switch to it. Just because it's systemd, doesn't always mean it's better. Just look at network manager vs systemd-networkd. Correct me if I'm wrong but afaik they are made to serve the same purpose and most distros prefer Network Manager over systemd-networkd.
Honestly, though, NM is useless on a server or VM. I don't know why they still have that kludge installed on 90% of machines.
Having said that. Lennart's Cancer is junk from junk process. It WILL be adopted by every distro but PCLinuxOS because no other distro is putting effort towards stability and reliability.
I'd hoped that moving to Microsoft would allow IBM to re-evaluate the shit shoveled into its declining enterprise product, but that's not looking likely given staffing and IBM's ancillary priorities. RHEL only needs to be Good Enough so it can sell certs and classes and AAP and other make-work.
If RHEL is as shit as you say, what do you recommend companies switch to?
Don't we already have polkit and pkexec for that?
invoking them is kind of a pain, my sole experience with it was meson/ninja using it but then that default was removed and I've never been able to put it back to satisfy my curiosity of how it's done
As long as it's not a mandatory switch, I can't see any issue with this.
In theory it isn't mandatory, in practice you will see a lot of distros replacing it.
You think?
Hardly anyone uses the built-in network stack or the homed thing.
Idk for the network stack, but for homed, I think it's because it is up to the DEs to support it. As part of the Sovereign tech fund, GNOME is implementing support for it! I think this will be a great step forward for Linux desktop security when it lands
It's the same drama as with the home directory replacement they announced and that no-one ever used.
homed isn't exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.
user-password based encryption of the home directory, so the password is required to unlock it (no admin access)
That seems like a very niche feature given that it is only relevant if the admin isn't the same person as the user but the admin would have to set it up and condemn themselves to hearing endless whining from users who lose their files when they forgot their password.
Let me introduce you to selinux.
In what way does selinux allow your users to lock themselves out of their own home directories in a way that the admin can not fix?
SElinux is a "global ACL." You can stop root from doing anything you like with it. Usually by accident and without realizing it's been done in my experience...
No, that is just not true. You can stop root from doing things without a reboot with SELinux but encrypting something with a password root does not know actually does stop them from doing it at all short of a brute force attack on the encryption.
That's true - you can often recover a bad ACL. I was thinking more of the "niche use case" where separating duties and restricting root are concerned.
Oh, I was specifically thinking that admins that have users either competent enough not to forget/lose their passwords or mature enough not to whine to the admin when that causes the loss of all their files are pretty niche.
no...nonono... AHHHHH! - Vegita DBZA
I don't know, unless I personally allow the admin to have that kinda access to my files I wouldn't really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.
However, distributions like Fedora will definitely be in the lead, judging by previous experiences and stories of adapting new Linux technologies and Systemd components.
I wonder if this is still true, now that he no longer works for RedHat, but Microsoft.
I wonder if this is still true, now that he no longer works for RedHat, but Microsoft.
Why wouldn't Fedora do that? Decisions are decided by multiple people, they are not forced through or just decided unilaterally by one person.
Enough people in Fedora try to improve the low level stuff. I'm looking forward to that homedir systemd stuff. Don't care about this sudo alternative.
Decisions are decided by multiple people, they are not forced through or just decided unilaterally by one person.
Unless you're talking about GrapheneOS, but that's an horror story for another night π€£
Glad to see PoetteringOS has still not infected the *BSD family members /s
And I'll gladly use Doas on Linux if need be, thank you.
What version of doas though? Opendoas is hardly maintained.
Whp is this "Lennart Poettering" character, anyway? I suspect he might be secretly working for Microsoft.
It stopped being secret a couple of years ago.
In the old days, it was Emacs trying to do everything. Now, it's the SystemD.
That was so bad that vim users needed to make nvim to handle Emacs envy, and every modern ide tries to do the same in worse ways.
(Not trying to start a holy war, I use both)
Dudes trolling, right?
Artix, Devuan, Void, Alpine Linux are the way to go
Also Gentoo and Guix as mentioned in the comments
Gentoo LET'S GO
You're absolutely right, I absolutely forgot about Gentoo although it's my daily driver
and Guix
No.
Can't see how this could go wrong
@starman
Systemd is nice. I miss GUI apps for #SystemD.
Permanent mounting a Network drive or creating new Services and inspect and modify is such a point.
Systemd monolith - worst thing to have ever happened to Linux
Wayland monolith - best thing to have ever happened to Linux
Wayland monolith
There seems to be misunderstanding about what Wayland is.
Wayland is set of protocols. They are implemented by wayland servers (compositors) and wayland clients (applications) themselves. There is no single "wayland binary" like in the X11 days. Servers or clients may choose to implement or not implement a specific protocol.
X11 is a protocol too. Xorg is the binary you are talking about
I think what they meant is that there are people that think: "Wayland is too fragmented, there should be 1 'Wayland Compositor' and the rest should be window managers"
Nope, I meant that the wayland compositors are inflexible monoliths that are so tightly integrated into a DE that they can't be replaced. Xorg might be bloated, but it follows the UNIX philosophy closely enough that each part of the stack above xorg can be trivially replaced.
I guess my interpretation was too charitable.
Nothing in the protocol prevents you from splitting the server from the window manager, just everyone implementing the wayland server protocol didn't see any benefit in splitting it out.
Thanks I didn't know that. Arcan seems to have kept WM's separate.
Thanks I didn't know that. Arcan seems to have kept WM's separate.
Wayland is set of protocols.
Oh my god! It's like hearing the same on hold greeting again and again. WE KNOW!
Sure, but that doesn't change the fact that Wayland compositors are forced to be inflexible monoliths that need to be so tightly integrated into a DE that they can't be replaced.
Edit: I've just learned that it's not forced, but that every compositor used by popular DEs is an inflexible monolith by choice.
In xorg the server, wm, and compositor all do their own thing and can be replaced trivially. It took me like 5 minutes to replace xfwm4 with i3, and that included the research.
They're also all shit and dysfunctional as hell. Xorg forever. Systemd good too.
MacOS 7 forever, in the same way
Oh you had me going in the first half. Sly devil you. Wayland still doesn't work on the fleet of equipment we have.
hey, many of us dislike both equally! (specially the push to become the only alternative)
I think wayland has potential but in it's current state it's just half baked. Once more protocols get merged, maybe in a decades time Wayland should be quite flexible and robust.
That's how I feel as well. IMO it's ridiculous that Fedora wants to remove xorg completely from the repos in the next version.
It is ridiculous. Nothing like says f you to a large percentage of your user base like pushing out a solution that doesn't work for them.
The wildest thing is that current xorg package is maintained by the community and they're still removing it completely because "xorg is taking up too much dev time".
More like over baked but still only half done.
It does have potential. I think anyone denying that is simply wrong. the issue with wayland is purely how slowly it moves and the fragmentation. Now the fragmentation is actually in large part due to how slowly it moves. There are numerous WIP protocols that will greatly decrease fragmentation when all are merged.
I can't wait because it seems like it will happen in the short future of one or two decades xD
If they had named it systemd-x11 people would hate it.
No fuckin thanks
Maybe that could be a good thing, but only if the distros do not include sudo by default, the fact to have one thing to update to update more things is good in the security side! If it's well implemented I'm okay with it
What you're refering to as Linux, is in fact, Systemd/Linux, or as I've recently taken to calling it, Systemd + Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning Systemd system made useful by the Systemd corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX
π€£
Thanks to BSDs we have sane alternatives :)
Oh it's no longer POSIX, he's seen to that!
ProgrammersAreHumanToo, great stuff.
When does systemd stop? Linux without it is increasingly looking unlikely in the future. Are we not worried about it being a single point of failure and attack vector?
This isn't a moan about the unix philosophy btw, but a genuine curiosity about how we split responsibilities in todays linux environment.
SystemD will consume the entirety of Linux, bit by bit.
I think you might want to recheck the ages of some of the people in your timeline, most of them aren't that young anymore.
Yes, because it's easier to take care of octogenarians than people who might actually put up a fight to having their laptop batteries replaced with a pipe bomb.
Debian already uses systemd.
Debian in many ways isn't as slow-moving as people think.
For example, they moved to Wayland by default (for Gnome anyway) in 2019. A number of well-known distros likely won't have that until 2025/2026 or beyond.
Sadly they've been dropping archs throughout the years, meaning they're no longer the distro you can use to run on "anything" from a pi to a mainframe...
Doesn't trixie still support like a dozen arches? I think one of the more recent deprecations was MIPS BE which is functionally obsolete in 2024, at least insofar as practically no one is using it to run a modern distribution.
Bookworm, Trixie, and Sid all currently support a total of 10 different architectures.
And looking through the Wikipedia article for Debian's version history, most of the dropped architectures were functionally obsolete when they were dropped, or like the Motorola 68000, when support was added. (notable exceptions being IA-64 which was dropped 4 years before intel discontinued it, SPARC which is still supported by Oracle, and PowerPC.)
If your bar is "modern distribution" stick to Ubuntu.
If you want to maintain older hardware Debian used to be a go-to solution.
What's the go-to solution now?
Most likely LFS or some tailored distro I haven't heard of.
Probably the weirdest joke comment I've ever read.
Thanks for that write up. Made my day! π
That comment was brought to you by an AI LLM. No one actually took the time to write that.
Nope, doesn't have any of the hallmarks of an LLM and LLMs aren't yet clever enough to produce original humor like that.
π₯΄
This is a script of Simpsons episode and Torvalds will actually die in 2058.
Dude if you made a movie or novel about this that would be awesome
One way to notice a person has "systemd derangement syndrome" is by looking at how they write
systemd: if they write itSystemDthey are already in late stages of SDS and it isn't curable anymore.Either that, or it's a joke.
"systemd announces a repleacement module for the kernel"
HurD
By this logic the Linux kernel is also a single point of failure and attack vector.
sudo isn't going away, so does doas. run0 is just another alternative to use or not.
There are still distribution out there without systemd and if there ever won't be any systemd-free distributions left and systemd would become a critical part of the Linux ecosystem, then it would get the same treatment as the Linux kernel with many professional maintainers.
plus, it isn't like this isn't exactly like adding another "door" to the "systemd building". It's a modular component of systemd, so more akin to replacing the sudo building with a new, but still separate, systemd sudo building
@Olap
I agree. As someone who uses systemd on daily basis (I use Arch, BTW π) I really like it, but I am a bit worried about it being a single point of attack. Maybe just push doas as default instead? I never used doas but I watched few videos about it, so I guess it's fine and probably better than sudo (less bloated).
Just my few cents.
I don't see how something would be inherently easier to attack if it is called systemd-foo instead of just foo. Attack surface and vectors do not depend on which project develops a particular tool.
I'd be willing to bet it's people fearing another xz-like situation
Gentoo, Slackware and Devuan can be used without svchost for linux.
They'll only stop when they rebrand it to systemd OS.
https://nosystemd.org has a list for more choice for readers.
Debian works fine without systemd too, there's a page on the wiki on how to install without it, or remove it after the fact.
Easy with
sudo apt remove --purge --allow-remove-essential --auto-remove systemd::-D Time to go outside.
A lot of debs add services to systemd, do those just skip that part?
They seem to. Debian explicitly supports multiple init systems, sysvinit being the primary alternative, so packages have to handle systemd-init not being there.
Systemd is a bit of a hassle to be rid off, but thankfully it's not actually that hard, the hardest part I found was converting systemd services to whatever init system I use.
I wonder how many hours you sunk into that practicality-free, weird-philosopy-dependent project
Probably not much time, a lot of packages come with init scripts anyway, and they're pretty trivial to write if not.
You can certainly argue it's a philosophical choice, I'd say it's more down to recognising the many poor architectural choices in systemd, rubbing agaist its many pain points and misfeatures and being alarmed at the size of the attack surface it exposes. I understand there is an effort underway to reduce the size and complexity of the main shared library to help address the last point, but just the fact that is necessary shows the scope of the problem.
Systemd is fine. If it wasn't, most distros wouldn't have switched to it years ago.
Let's agree to disagree on that point. Redhat switched because they invented it, and so took all the RHEL derivative distros with them. Debian switched to prefer it after a rather contentious vote and so took all the Debian derivative distros, including Ubuntu, with them. That just leaves a lot of the smaller distros, most of which seem to have stuck with sysvinit or similar as far as I can see.
The arguments against systemd are very unconvincing but more importantly, there is zero evidence that they actually matter.
And it works.
Further, in order to represent this as a nearly unilateral decision you failed to mention that arch, centos, and opensuse all opted in independently.
And no offense but angry Internet randos arguing software philosophy will never convince me to disagree with the creator of the Linux kernel.
Linus Torvalds said:
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
I obviously find the arguments against systemd more persuasive than you do, and that's fine, it's all open source and we can all make our own choices about it. My experience with it over the years has been, and still is that it vastly over complicates things that used to be simple, often the less commonly used parts just don't work right (the automounter is a particular bugbear of mine, and few distros seem to use the network management component). The arguments do matter in practical terms as they directly impact how it works.
Of the distros you mentioned, centos is a RHEL derivative and so wasn't independent, arch packages multiple init systems, but yes, I'd forgotten opensuse, and they seem to be firmly in the systemd camp.
I may be an internet rando, but I'm not actually angry, more just disappointed. I'd agree with Mr Torvald's opinion that some of the design details are insane, but I think they are more fundamental than just 'details' as many are to do with the fundamental concepts around what systemd is and how it works. Linus can be a real dragon around changes to the kernel, but he's always tended to be more relaxed about the layers above it.
That the developers of systemd are 'much too cavalier about bugs and compatibility' is surely clear to anyone who follows the relevant mailing lists and bug trackers, and should alarm everyone.
That quote carries the opposite connotation of what you seem to take from it. He's saying despite having issues with the devs, he acknowledges those issues probably don't matter.
I admit I don't understand the internals of any of these systems. But I do understand that if the creator of the kernel isn't concerned about systemd, and that if the vast majority of distros use systemd, then it indeed works well enough. The systemd apocalypse never happened and likely never would happen.
I see this argument as software conservatism. The rest of us will be okay with the thousands of knowledgeable developers that seem to think systemd works just fine.
I'm not disputing that he doesn't think the issues are major, as I said, he's usually pretty ambivalent about what runs on the kernel, so they're not issues he cares about. On the flip side, I do care what is running because I have to manage and support it.
I do wonder if we're talking at cross purposes though. You seem to mostly be talking about the systemd init system, I'm mostly talking about all the other bits it, as a sort of umbrella project, tries to encompass. I don't much like the init system, I prefer to be able to explicitly set the ordering of the steps, rather than having them inferred, and I prefer shell script that I can test to unit files, but it mostly works ok. So does every other init system though, so it's not a selling point.
As I said, the big problem is around how they've tried to do everything, much of it less well than what they're replacing. Yes, you can build a system that uses systemd-init and none of the other components, but that still drags in a load of other dependencies, so you might as well use a different init that's smaller and cleaner.
We came close to the 'systemd apocalypse' recently, when distros hooked the systemd library into openssh without understanding just how bloated it is and how many poorly monitored dependencies it brought in. It was just luck that the right person spotted a slight change in timing and investigated.
Ultimately I suppose it comes down to the level you interact with your systems at. If you just want to install your OS, a few packages they directly support and let it get on with it, then you probably neither know nor care that you run systemd, and that's great. On the other hand, in my experience, when you try to push the system past that and do anything more customized you start running into the sharp edges and misfeatures on the various systemd components.
took me about an hour to get started with artix originally, and maybe a couple more to really familiarize myself with the init. As for practicallity, it's been a large improvement for me.
Soon we will have to call it GNU/systemd/Linux
Nah. Replacing the kernel is probably planned for the next point release - it'll just be GNU/systemd
Can we rename it GNUtriSystemD?
I mean it should kind of already be something like GNU/SystemD/X11/PipeWire/Linux, I guess.
It's not like the GNU utils are the only massive integral part of the OS. I think GNU/Linux caught on squarely because many people follow Stallman, and that's how he wants people to refer to it.
It definitely made way more sense at early on. I mean GNU made most of UX of using Linux at some point. Systemd, and the browser now make a much bigger portion than before, and the world is more than GNOME now too.
Systemd makes life easy. It also makes Linux more teachable. I like accessibility and donβt even mind this
hard disagree. life with plain text logs and daemon init scripts was so easy and nice. But we can't have nice things...
Those hacked together system-specific bash scripts were shit. Having a standard way of creating, starting, ensuring restarts,and logging services is so much better.
You can still get all the plain text logs you like.
With a different feature set per script as well. The systemd service files have often been pushed upstream.
Pretty sure people liking those scripts never really tried dealing with them across distributions. Though this just rehashes things that were said when distributions decided if to switch to systemd. Still the same strange claim that those scripts are somehow easier. It wasn't, it is also way easier to package a systemd file from upstream than to maintain that stuff within a distribution.
How do you get plain-text logs instead of the garbage binary format that
journalctlforces on you?Set ForwardToSyslog=yes in journald.conf and install a syslog daemon. Also optionally Storage=volatile (I wouldn't set Storage=none unless you want systemd to no longer show you any logs anywhere including in systemctl status because I assume it will do that)
Thank you!
Definitely reads like a Microsoft answer, seems so much easier than just reading text
By configuring journald to forward messages to syslog as is the default.
"forces on you" π
Edit: Systemd has been around for 14 years. Did you never think to google this?
It's not the default fwiw. From journald.conf(5):
You know what's nice? Being able to sit down at any Linux distro and being able to set up and configure services without Googling how to use that particular distro's init system.
But it's so unbearably slow.
Me when my computer that has a typical uptime of 37 days boots up in 7 seconds with systemd instead of 5.5 seconds with runit: π‘π‘π‘π‘
Lmao yeah exactly
I'm not on the systemd hate train by any means, but I don't understand how this is any improvement over
pkexecThat has the same problem as
sudo: the SUID bit is set for it.The fact that
run0uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone cansystemctl status, butsystemctl rebootneeds to be in thewheelgroup) which is why its generally used within systemd already. And it wouldn't surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.I'm unclear from the documentation, does pkexec work under non-GUI contexts?
As long as you have polkit setup to work in terminal sessions, yes. This is pretty standard these days, though not particularly widely used.
Or as I've taken to calling it, GNU+systemd+Linux.
https://news.ycombinator.com/item?id=40217813
Not that I'm opposed to a better sudo alternatives, but I find it rather ironic that one of the reason stated is the large attack surface, considering systemd is a massive attack surface already.
This isn't exactly a "new" attack surface, so removing the attack surface that
sudo(and alternatives) is, is probably a net positive.That attack surface is not vanishing. It's would be relocating the same attack surface to something that might have an xz library in memory.
systemd-run, which is calling into PID1)dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)As Microsoft and Poettering intended.
feature creep
I'm no Linux expert, but I've never had any problems with sudo, it just works. Shouldn't systemd have higher priorities on their mind? This feels like change for the sake of change. And if this does happen, I sincerely hope that it just works, like sudo.
I think the article (or more Lennart Poertting post) explains it quite nicely. The problem with sudo is that the sudo binary itself has the ability to gane elevated privileges which is a potential attack surface
There's a rewrite of sudo happening in rust, but he wants to throw out the SUID idea altogether?
That sounds like opening up the door to what windows is doing UAC and the wonderful vulnerability that the GOG Launcher had for privilege escalation.
I'm not a security researcher, but giving arbitrary users the ability to tel PID 1 to run a binary of the user's choosing is... probably not what Pottering is suggesting, but opens up to such vulnerabilities. And if it's written in C/C++ my trust is further reduced.
Anti Commercial-AI license
Giving users access to PID1 running binaries, giving users access to the kernel running binaries as root, I don't see much difference. SUID was notorious in the past for being leaky, it only ended when distros got serious about fencing use of it in, giving it only to programs actually needing it, making sure that they drop privilege properly, etc.
If anything I'm in the PID1 camp because it's more microkernely. But in any case broader userspace shouldn't really care about the mechanism, only have an API to do it and that API being a bit in the file permissions is soooo 1960s.
Do you trust Linux? Because if so, have I got news for you.
Wait until they hear the language used to implement OpenBSD. Imagine being one of the authors of seL4 encountering a member of the rust cult.
Oh, it's gonna use polkit. Sudo bloat is a grain of sand compared to polkit.
Why people want to replace sudo with polkit? Visudo is no near as obscure as configuring polkit.
I hope distro maintainers don't follow this.
...is
pkexecnot good enough already as a polkit based sudo replacement? Why would one need to systemd-ify that?I just treat polkit as "set it and forget" kind of thing and leave it on defaults, I'd rather spend my time on something more important
They can't help themselves. They gorge themselves on his phallic offerings.
First thing I do with any new desktop installation is disable polkit prompts.
Fuck having to enter my password every time I want to do something.
Hey uh can I get your IP address real quick? I have a strong suspicion your philosophy extends to your network ports.
You'd be wrong about that.
Edit: he just downvotes me instead of admitting he's wrong about his assumption, lol.
sudois already an optional component (yes, reallyβI don't have it installed). Don't want its attack surface? You can stick withsuand its attack surface instead. Either is going to be smaller than systemd's.systemd's feature creep is only surpassed by that of emacs.
Tomorrow's headline: emacs wants to expand to include a Sudo replacement
And after that: emacs wants to include a systemd replacement
:wq
I'd take that over systemd.
But systemd is modular. They make an offer and distro maintainers and admins get to choose which parts to use
The problem is that those modules are packaged by the developers as opt-out rather than opt-in. It's a variation on Microsoft's old embrace-extend-extinguish playbook, only the "extinguish" part hasn't worked so well because there are some stubborn distros whose needs don't align with what systemd provides and have maintainers that go out of their way to provide alternatives.
(By contrast, although we may joke about emacs, it's the myriad of third-party extensions that cause it to just about be its own operating systemβit doesn't all ship with the core.)
Or you can use a
doasimplementation like OpenDoas, or maybesudo-rs...Though a Rust clone of sudo that operates in the same way will still have the same problems.
And there's also doas which is a nice substitute.
I'm not a fan of having root be able to actually login.
Even more so in a true multiuser env where I would rather have privilege escalation be more granular (certain user/groups can esculate certain actions but not others, maybe even limit options of a cmd).
Granted, in a true multiuser environment with an admin who's carefully tailoring /etc/sudoers to make sure everyone has the least possible privileges that will allow them to still do what they need,
sudois more secure. There's no doubt of that.On a machine that has only one human user who's also the admin, and retains the default sudo-with-user-passwords configuration,
suvssudois pretty much a wash, security-wise.surequires a second password to get root access, butsudotimes out and requires the password to be re-entered while a shell created bysucan stay open indefinitely. Which is more easily broken will depend on other details of your situation.(If you're running an incorrectly configured ssh server that allows direct root login with only password authentification, having a root password could contribute to problems, but the correct fix there is to reconfigure the ssh server not to do something so stupid. I hope there's no distro that still ships that way out of the box.)
A lot (and I mean a lot) of criticism can be leveled at systemD. One of the upsides of it becoming popular is the standardization of much of things from the developers' perspective. It's easier to target multiple distros when you can rely on systemD's single implementation of the feature. Over the next decade, I forsee systemD eating more and more of the userspace, until you are only left with managing the differences between DEs and which display server they are using. We're already headed towards immutable base systems with apps shipping with their own dependencies, which we reduce the differences between distros even further.
Maybe they'll add a DE as well?
Just kidding!
systemde
SystemDE
Don't give them ideas π
If Canonical and RedHat weren't backing different horses (Snap vs Flatpak), I could see the app containerization system coming under systemD as well fairly soon. The Cosmic DE project uses functionality from systemD to overlay changes onto the system that are reversible, so that alpha versions of Cosmic can be tested without permanently changing the base system. Imagine apps shipping on whatever container runtime, and dynamically overlaying system-level changes as needed for things that tap into the host system via systemd-sysext.
gross!
This is great. Not having the attack surface of
sudo(and not even being a SUID binary) certainly are great additions.And I hope people realize that
systemdis not one large thing, but a (large) collection of tools.The attack surface will be a systemd daemon running with UID=0 instead, because how else are you going to hand out root privileges?
So it doesn't really change anything to the attack surface, it just moves it to a different location.
That already exists.
systemd-runis already available today. So the attack surface would be smallerNot really, because you're now going to make it do more, i.e. incorporate the functionality of sudo and expose it to user input. So unless you can prove that the newly written code is somehow inherently more secure than sudo's existing code, the attack surface is exactly the same.
Who don't work without Systemd. And Systemd can't coexist with tools in the same repo doing the same job in a portable way.
I think Chimera was it (?) which tried to have Systemd and Runit and others in the same repo. With lots of wrappers and shims. Not because of Runit & co.
Just like gnu utils.
But gnu utils work on BSD and others, while Systemd is Linux only.
Right. That reminds of the time I was visiting a friend who had broken his Linux computer (No, not "apt-get remove --purge systemd" but they did something slightly similar). When I booted from a live Linux, used chroot and wanted to use configure networking : FAIL because systemd was ... not running. As he had no Internet because of his broken machine this caused some delays in fixing this but we got the job done eventually.
XZ-utils rings a bell ? It was among others Debian wanting to pull in part of a systemd tool into openssh and that almost turned into a world wide disaster :(
I didnt understand that sentence. Is that what you meant?
xz is not part of systemd or openssh afaik.
You didn't follow the XZ-utils story ? The malicious actor worked for years on that XZ backdoor that targeted the fact that some Linux distributions were modifying their openssh package to enable systemd notifications.
Ok true, it was a systemd dependent issue. But it only makes sense to have those notifications. The problem is dependency on small hardly maintained products, which systemd will improve by centralizing it.
And where do maintainers for the new parts of systemd come from? The larger systemd grows the more parts of it will be neglected. Also in regard to people checking commits, opening up doors for exploits like the one in xz.
I dont know but for sure has pros and cons
Maybe in your mind it makes sense. Going for ease of use rather than security is not something that OpenBSD would quickly do. If you read some more about what "jwz" has to say about all the screensaver bugs in Linux, like here : https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition and realize what a mess that Linux maintainers are making again and again, and then have a look at Debian and their packaging of xscreensaver. Guess what ? Debian added some systemd thingie to xscreensaver. π€―
I like Debian since a long time and I use it. But the tinkering of Debian package maintainers and always wanting to do things the Debian way is not something I am always very pleased with. Remember the OpenSSL Debian fiasco ? That shows a problem with Debian which may still exist. Too many packages, not enough maintainers with enough spare time, and no coherent team work of a security team.
You are talking about Debian holding back random packages for stability. This is of course not very cool but it needs to be tested.
I am very much in favor of isolate app environments controlled by upstream devs, containerized and with a permission system. The system is made by the distro, and can be stable and very tested, and the apps are simply isolated and made by upstream.
There is no xscreensaver on Wayland and I think this will not come back?
Kinda feels like writing a script that implements the
sudoCLI but callspkexecwould be an easier way to do it. Given that so many systems already come with bothsudoandpkexec, do we really need yet another option?The point of this is to implement some form of privilege escalation without the SUID mechanism.
sudo,pkexecanddoasare all SUID.I've had to scroll down eight pages to find a post that seems to actually address the good points raised in the article.
I honestly started out not liking systemd at all, mostly due to the reports that it did waaay to much, but nowadays, I like the concept.
It is basically officially moving daemon management from a script-based approach to a table/database-based approach. That improves static analyzability, therefore increasing clarity, and probably even performance.
I agree that we should abandon scripts and move towards declarative software management, and abandoning
sudofor a more declarative system seems like a good step to me.So I don't even use systemd myself I run OpenRC. Yet honestly I find the idea quite intriguing, having the service manager (PID 1) invoke the command seems like a cool idea to me.
It's not really a sudo alternative as much as it is another way of doing something similar.
How does
systemd-run/run0handle what/etc/sudoerscurrently does?I'm disappointed in how little technical discussion there is in this thread.
Looking at the implementation, it doesn't really implement sudoers or tools like sudoedit in any way.
systemd-runhas already been an existing tool for quite some time and this is really just a different CLI for it. That tool asks systemd to make a temporary new service and immediately run it. That, in turn, requires blanket yes/no approval fororg.freedesktop.systemd1.manage-unitsvia polkit.So with run0, you can either do everything or you can do nothing. In-betweens are just not a thing at the moment. There's very little new backend code running as root.
run0 bashshould behave very similar to something likesystemd-run --uid=0 --gid=0 --wait --same-dir --send-sighup --pty --pipe --collect bashand the majority of those options have been available for quite a while.Idk
Systemd has always been about "don't ask questions or well call you obstructionist and old".
sudo is overkill for most users tbh
so is systemd
Actually no. The thing is just that systemd handles so many things that makes the lives both developers/distro maintainers and users easier, but most of it happens in the background. You can forget about having to learning complexer tools, just do it all via systemd
Yeah I think I'm the exception but I just use
suat homeSurprised people aren't moaning about systemd being too big already and still wanting to do more.
It's too big!
π
That's what somethin' somethin' said lastnight, Trebek! ;)
SPoF !!!! Ahhhhh we all dead
The comments are here now, you can come check again π
π
Systemdeez nuts
Gentleman and scholar
The meme is becoming a reality. Systemd really is going to try to be everything lmao
AlwaysHasBeen.jpg
But for why (I'm commenting this before reading) wouldn't it make more sense to home I'm the scope of systemd so it can be easier to maintain? Why have it do everything?
systemd is more of a set of products and software components branded under a single name rather than a single thing.
systemd itself is rather simple, as most other pieces systemd-* software, like systemd-boot, systemd-networkd and systemd-resolvd. these are usually more stable and less bloated than more popular alternatives
As long as they can work independently, yes. If they are modular and a distro admin (or just a computer admin) can choose to install and use systemd-x but not install or use systemd-y, we are in good business
Now if you have to take a few you don't like or need to use so that the one component you do want works, then no
I honestly don't know enough of systemd to say either way
Most of systemd stuff is decoupled well. You don't need to use networkd to make use of resolved for example.
Good to know, thanks for the answer
Oh okay I didn't know that thanks
You can't think of it a single massive project. It's actually lots of small components.
We could argue the linux kernel is bloated too. The reality is though, provided the project is designed to be modular (as SystemD is), it actually makes sense to keep it together, to ensure there is a standard base and all the components are synchronised fully with their API's.
It also saves distro's a lot of effort.
You can pluralize without the apostrophe. In fact, you never need an apostrophe to pluralize.
Only if they want to break free.
And they don't need nfsroot or a separate consolidated /usr mount or, really, a whole host of things that lennart didnt understand and unilaterally broke like an arrogant noob.
But that's blasphemy.
In practice, all those tight coupling between components mean that it behaves more or less monolithic, despite the claims to the contrary. Replacing them with alternatives is a pain because something else breaks or some software has a hard dependency on it.
Oooh okay that makes more sense. Thanks I didn't know that
I can understand that it makes it easier to add changes that would benefit systemd and distros in general. I read that they introduced run0 to solve long shortcomings of sudo (I'm not aware of which). That sounds logical.
Isn't the guy behind systemd a (former?) Microsoft employee? I feel as though that might offer a clue as to why the trajectory towards bloat.
He's working for Microsoft now but it's very recent, he developed systemd while working at RedHat.
I don't even know of he's still working on it. There are a lot of things to be said about systemd and Lennart but the link to Microsoft is irrelevant.
It is. He is poisoning Linux, slowly, from the inside. Like the XZ attack, just smarter and much slower.
The guy who discovered the xz attack was also a Microsoft employee, for what it's worth.
Maybe they discovered xz attack because they are familiar with these things.
Why do you consider it as poisoning? I've heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?
Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they're a very welcomed feature imo
By itself, solely doing init, it would have been fine, however, binary logging (even if you eventually end up with a text log, that's wasting disk space on a binary format no one wants or needs), and it didn't stop there. He keeps replacing Linux subsystem after subsystem, and many of those replacements are not progress, just duplication of effort and creates more ways for configuration drift.
Here is the rationale for the Journal. In short it is really not that simple and it has a lot of advantages over simple text files and it saves disk space.
Having the logs twice is saving space, got it. Do you hear yourself?
You can still forward to text syslog or to a central logging server like Loki if working with multiple hosts. I still don't get the issue with binary logs.
Yes, and many distros have that out of the box... But they don't have it sent to keep the binary journal as close to empty as possible. So you end up with twice the space in use for logs. As for the issue with binary logs, text logs can be read by far more tools and utilities, rather than just journalctl and pipes.
You can set the space limit for journals logs really low then, to avoid double space usage. As for the last argument, that also was an issue for me years ago because not all tools were compatible with the journald format, but that's since long fixed now and I've not experienced any issue for a long time. Journal logs provide a standard format for all applications, so third party tools don't need to be compatible with every log format of your applications. And it also comes with great additional features like -b or --since etc. So I still don't get the issue here
The issue is logs are suppose to be text. Seriously, wtf. You some Poettering fan boy or something?
I was arguing how it is a very useful tool with many great additions, rather than rely on the: "no old better!" reply based on ignorance. But it looks like your replies have turned full removed, so no point in continuing here to try and educate you.
Text is compatible with all the grep, awk, sed, text editors, what have you. As for the argument of it binary saving space, not on modern filesystems with compression, like zfs, btrfs, and bcachefs. The entire resistance against tampering is bogus, any systems where that is a concern already live scrape logs to an off server indexing service. If you are concerned about poorly formatted logs, that is an application configuration issue. Address it directly with the application. There are no benefits to a binary log, especially when journalctl is absolutely no faster at jumping to the end of the long log than standard less is. Poettering has you chasing phantoms. He always does. He's like the politician who justifies horrible bills by saying it's to protect the children.
Well... Poettering will eventually work his way up to browser engines and then we'll get something efficient... Here's the announcement:
"There's a new component in systemd, called "engined". Or actually, it's not a new component, it's actually the long existing "WebKit" engine now done properly. The engine is also a lot more fun to use than "WebKit" or "Blink" because you can finally have hundreds of tabs open in your browser without running out of RAM.
Coming soon in Coming for systemd 981.
I'm not surprised. Not surprised at all. (scope creep)
new sudo vulnerabilities? how exciting!
E: read the article, I guess that is part of the reason for the proposal. interesting
Even when that releases, it doesn't mean distros will switch to it. Just because it's systemd, doesn't always mean it's better. Just look at network manager vs systemd-networkd. Correct me if I'm wrong but afaik they are made to serve the same purpose and most distros prefer Network Manager over systemd-networkd.
Honestly, though, NM is useless on a server or VM. I don't know why they still have that kludge installed on 90% of machines.
Having said that. Lennart's Cancer is junk from junk process. It WILL be adopted by every distro but PCLinuxOS because no other distro is putting effort towards stability and reliability.
I'd hoped that moving to Microsoft would allow IBM to re-evaluate the shit shoveled into its declining enterprise product, but that's not looking likely given staffing and IBM's ancillary priorities. RHEL only needs to be Good Enough so it can sell certs and classes and AAP and other make-work.
If RHEL is as shit as you say, what do you recommend companies switch to?
Don't we already have polkit and pkexec for that?
invoking them is kind of a pain, my sole experience with it was meson/ninja using it but then that default was removed and I've never been able to put it back to satisfy my curiosity of how it's done
As long as it's not a mandatory switch, I can't see any issue with this.
In theory it isn't mandatory, in practice you will see a lot of distros replacing it.
You think? Hardly anyone uses the built-in network stack or the homed thing.
Idk for the network stack, but for homed, I think it's because it is up to the DEs to support it. As part of the Sovereign tech fund, GNOME is implementing support for it! I think this will be a great step forward for Linux desktop security when it lands
It's the same drama as with the home directory replacement they announced and that no-one ever used.
homedisn't exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.That seems like a very niche feature given that it is only relevant if the admin isn't the same person as the user but the admin would have to set it up and condemn themselves to hearing endless whining from users who lose their files when they forgot their password.
Let me introduce you to selinux.
In what way does selinux allow your users to lock themselves out of their own home directories in a way that the admin can not fix?
SElinux is a "global ACL." You can stop root from doing anything you like with it. Usually by accident and without realizing it's been done in my experience...
No, that is just not true. You can stop root from doing things without a reboot with SELinux but encrypting something with a password root does not know actually does stop them from doing it at all short of a brute force attack on the encryption.
That's true - you can often recover a bad ACL. I was thinking more of the "niche use case" where separating duties and restricting root are concerned.
Oh, I was specifically thinking that admins that have users either competent enough not to forget/lose their passwords or mature enough not to whine to the admin when that causes the loss of all their files are pretty niche.
no...nonono... AHHHHH! - Vegita DBZA
I don't know, unless I personally allow the admin to have that kinda access to my files I wouldn't really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.
I wonder if this is still true, now that he no longer works for RedHat, but Microsoft.
Why wouldn't Fedora do that? Decisions are decided by multiple people, they are not forced through or just decided unilaterally by one person.
Enough people in Fedora try to improve the low level stuff. I'm looking forward to that homedir systemd stuff. Don't care about this sudo alternative.
Unless you're talking about GrapheneOS, but that's an horror story for another night π€£
Glad to see PoetteringOS has still not infected the *BSD family members /s And I'll gladly use Doas on Linux if need be, thank you.
What version of doas though? Opendoas is hardly maintained.
Whp is this "Lennart Poettering" character, anyway? I suspect he might be secretly working for Microsoft.
It stopped being secret a couple of years ago.
In the old days, it was Emacs trying to do everything. Now, it's the SystemD.
That was so bad that vim users needed to make nvim to handle Emacs envy, and every modern ide tries to do the same in worse ways.
(Not trying to start a holy war, I use both)
Dudes trolling, right?
Artix, Devuan, Void, Alpine Linux are the way to go
Also Gentoo and Guix as mentioned in the comments
Gentoo LET'S GO
You're absolutely right, I absolutely forgot about Gentoo although it's my daily driver
and Guix
No.
Can't see how this could go wrong
@starman
Systemd is nice. I miss GUI apps for #SystemD.
Permanent mounting a Network drive or creating new Services and inspect and modify is such a point.
https://xkcd.com/1200/
Well I'm not a fan of systemd to begin with...
This is why people don't like systemd...
Systemd monolith - worst thing to have ever happened to Linux
Wayland monolith - best thing to have ever happened to Linux
There seems to be misunderstanding about what Wayland is.
Wayland is set of protocols. They are implemented by wayland servers (compositors) and wayland clients (applications) themselves. There is no single "wayland binary" like in the X11 days. Servers or clients may choose to implement or not implement a specific protocol.
X11 is a protocol too. Xorg is the binary you are talking about
I think what they meant is that there are people that think: "Wayland is too fragmented, there should be 1 'Wayland Compositor' and the rest should be window managers"
Nope, I meant that the wayland compositors are inflexible monoliths that are so tightly integrated into a DE that they can't be replaced. Xorg might be bloated, but it follows the UNIX philosophy closely enough that each part of the stack above xorg can be trivially replaced.
I guess my interpretation was too charitable.
Nothing in the protocol prevents you from splitting the server from the window manager, just everyone implementing the wayland server protocol didn't see any benefit in splitting it out.
Thanks I didn't know that. Arcan seems to have kept WM's separate.
Thanks I didn't know that. Arcan seems to have kept WM's separate.
Oh my god! It's like hearing the same on hold greeting again and again. WE KNOW!
Sure, but that doesn't change the fact that Wayland compositors are forced to be inflexible monoliths that need to be so tightly integrated into a DE that they can't be replaced.
Edit: I've just learned that it's not forced, but that every compositor used by popular DEs is an inflexible monolith by choice.
In xorg the server, wm, and compositor all do their own thing and can be replaced trivially. It took me like 5 minutes to replace xfwm4 with i3, and that included the research.
They're also all shit and dysfunctional as hell. Xorg forever. Systemd good too.
MacOS 7 forever, in the same way
Oh you had me going in the first half. Sly devil you. Wayland still doesn't work on the fleet of equipment we have.
hey, many of us dislike both equally! (specially the push to become the only alternative)
I think wayland has potential but in it's current state it's just half baked. Once more protocols get merged,
maybe in a decades timeWayland should be quite flexible and robust.That's how I feel as well. IMO it's ridiculous that Fedora wants to remove xorg completely from the repos in the next version.
It is ridiculous. Nothing like says f you to a large percentage of your user base like pushing out a solution that doesn't work for them.
The wildest thing is that current xorg package is maintained by the community and they're still removing it completely because "xorg is taking up too much dev time".
More like over baked but still only half done.
It does have potential. I think anyone denying that is simply wrong. the issue with wayland is purely how slowly it moves and the fragmentation. Now the fragmentation is actually in large part due to how slowly it moves. There are numerous WIP protocols that will greatly decrease fragmentation when all are merged.
I can't wait because it seems like it will happen in the short future of one or two decades xD
If they had named it systemd-x11 people would hate it.
No fuckin thanks
Maybe that could be a good thing, but only if the distros do not include sudo by default, the fact to have one thing to update to update more things is good in the security side! If it's well implemented I'm okay with it
Fuck off Poettering!