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

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.

Soon we will have to call it GNU/systemd/Linux

It's still missing core functionality for an init system, like a display server protocol, compositor, desktop environment and web browser smh.

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.

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.

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.

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.

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.

Anti Commercial-AI license

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.

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.

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.

Surprised people aren't moaning about systemd being too big already and still wanting to do more.

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.

How does systemd-run/run0 handle what /etc/sudoers currently does?

I'm disappointed in how little technical discussion there is in this thread.

Systemdeez nuts

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?

The meme is becoming a reality. Systemd really is going to try to be everything lmao

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