Run0, a systemd based alternative to sudo, announced

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The article explains how this sudo replacement ties to systemd:

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

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

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

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

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

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

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

> I am very glad to have jumped ship from systemd.

All that aside, so am I.

Is that really how they develop software?

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

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

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

"1 million lines of code for PID0!"

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

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

Isn't this just textbook FUD?

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

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

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

But anti-systemd people will dislike it automatically.

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

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

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

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

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

Same idea with systemd-run.

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

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

>systemd has long stopped being just an init system.

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

>Systemd already handles logins

Exactly that was my objection.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Obviously one of these groups is lying.

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

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

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

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

That sounds like a job for systemd.generator.

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

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

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

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

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

> their "portable and stable" APIs

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

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

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

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

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

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

What qualifies you to make a determination like that?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Systemd is DESIGNED to be an all or nothing deal.

^[Citation needed]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> This is literally just basic systems engineering

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

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

True

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

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

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

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

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

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

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

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

This is such an absurd hill to die on.

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

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

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

Do you understand the difference?

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

Units are not just for services.

From systemd.unit(5) man page:

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

userv has been around for decades

https://www.chiark.greenend.org.uk/~ian/userv/

GNU didn't. Why should Systemd?

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

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

or OpenBSD

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

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

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

You can't take OpenRC away from me!

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

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

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

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

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

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

Reasons:

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

- the Unix philosophy seems to be applicable here

- the result should be portable to non-systemd systems

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

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

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

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

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

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

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

> and they're all portable...

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

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

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

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

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

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

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

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

> the Unix philosophy seems to be applicable here

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

> the result should be portable to non-systemd systems

Portable on what basis? POSIX?

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

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

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

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

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

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

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

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

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

This:

| Systemd already handles logins

?

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

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

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

> Portable on what basis? POSIX?

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

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

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

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

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

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

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

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

This fetish of "everything should just stick with libc and POSIX" needs to go. These standards have not evolved at all, they are decades behind and don't even remotely cover the necessary requirements for implementing a "sudo replacement service". Just stick with sudo then.

> You can't use any GNU project without depending on GNU libc.

Of course you can. Unless they're depending on non-standard parts of libc, you can use any GNU project with other libc implementations (musl, dietlibc, ulibc etc).

But userv requires code to be written specifically to work with userv, even for seemingly simple tasks as reading files.

See 6.6 Error handling and input streams (eg stdin) on https://www.chiark.greenend.org.uk/~ian/userv/spec.html/ch-n...

systemd's run0 on the other hand doesn't require code to be written specifically to work with it.

I expect that when I run "sudo rm /foo" it should try to affect the same file as "rm /foo". Especially when I just checked, without sudo, that /foo was the correct file.

If there is a non-error effect in running sudo rm /foo, then indeed it should have the same effect as rm /foo as root in the chroot environment.

But using sudo, or even root, in a chroot environment isn't good security practice in the first place. For example, the environment's /etc/sudoers, /etc/shadow, /etc/passwd can all be different (but actual user ids are shared), while the environment could mknod the root filesystem device, mount parts of the host under /usr and /home and quite possibly elevate its access to the host filesystem, in which case sudo in a chroot environment would interact with the host in perhaps ways that are not directly constrainable in sudoers in the first place.

I imagine it's possible to carefully construct the chroot environment and craft /etc/sudoers in a way to avoid this, but I wouldn't even try.

In a better contained system implemented with namespaces (as in docker) sudo should work as expected. I imagine e.g. with docker you could have a service that responds to the system dbus messages, either as a separate daemon in the container or something even provided by docker itself. Or, maybe the requests from the container could be forwarded to the main systemd, with information about the context the request comes from, and let it choose how to move forward.

In the end I don't think I agree that a sudo replacement exchanging messages directly with the systemd is the best way to go. There could be another daemon, run by systemd (or not), that handles these messages. I suppose in the case of dbus there is no "dbus firewall" to limit the access to dbus as one can limit access to Unix domain sockets with plain old permissions, though, so perhaps the security benefits would be minimal in the dbus architecture.