Lennart Talks Up The Power Of systemd-sysext For Testing /usr Changes

[jacob]

You asked what this provided and I answered standardization. What's in bold is what I meant by standardization.

So, let me get this straight, you knew what it provided and asked anyways? Did I pass the test? Do I get to pass go and collect $200?

Then reread the post. I asked what advantage would there be to doing it manually using overlayfs without systemd. You said standardisation, which left me bewildered.

[jacob]

When will systemd swallow up the Linux kernel?

systemd never swallowed up anything, that's a recurrent myth. Some systemd developers decided to merge *their own* projects into the systemd suite, that's different. The one exception is consolekit which was abandonware. You are free to think that picking up and resurrecting an orphaned package is a crime against humanity of course.

[sinepgib]

Some systemd developers decided to merge *their own* projects into the systemd suite, that's different.

And even then, if that's so problematic, fork the original project. Oh right, people like to complain but they don't like to put the effort :^)
Of course, kudos to those who actually do, like the guys from eudev or the folks who decide to actually maintain systemd-free distros. Everyone else protests too much.

[jacob]

And even then, if that's so problematic, fork the original project. Oh right, people like to complain but they don't like to put the effort :^)
Of course, kudos to those who actually do, like the guys from eudev or the folks who decide to actually maintain systemd-free distros. Everyone else protests too much.

Of course. It's the same people who whine that systemd is "closed" and "proprietary". It's LGPL but the problem is that those people know shell, reading and understanding C is beyond their capabilities.

[sinepgib]

Of course. It's the same people who whine that systemd is "closed" and "proprietary". It's LGPL but the problem is that those people know shell, reading and understanding C is beyond their capabilities.

I may be biased because I know (enough?) C, but I don't think it's beyond any programmer's capabilities... Provided they have the will to learn. If they don't want to then cry me a river, take your freebie and don't complain.

[jacob]

I may be biased because I know (enough?) C, but I don't think it's beyond any programmer's capabilities... Provided they have the will to learn. If they don't want to then cry me a river, take your freebie and don't complain.

I would concede that reading C code full of low-level concepts, syscalls and APIs that only exist on Linux (memfd, cgroups etc) is not the easiest thing to get into for somebody who was never exposed to it before. Especially since it's true that systemd does lots of things differently from the UNIX-like systems (usually for a good reason though). But as you say, take your freebie and don't complain, or use Devuan or BSD or whatever.

[sinepgib]

I would concede that reading C code full of low-level concepts, syscalls and APIs that only exist on Linux (memfd, cgroups etc) is not the easiest thing to get into for somebody who was never exposed to it before. Especially since it's true that systemd does lots of things differently from the UNIX-like systems (usually for a good reason though). But as you say, take your freebie and don't complain, or use Devuan or BSD or whatever.

OK, that's true. It takes years of learning really, so I get the frustration when things change under your feet and you're not ready.

[Terrablit]

It's a bit funny to see people minimizing the work or value of this by referencing out-of-tree drivers like aufs and scripts (which clearly aren't additional dependencies, but distro-included tools are) or old "distros" that haven't been updated in almost a decade. Yes, you can already do filesystem overlays. Yes, people have built a lot of custom tooling around overlayFS. And yes, even the things referenced weren't the first of their kind. Niche solutions that aren't maintained are great for historical purposes, but pulling them out when a new solution comes is just weird hipster elitism.

Beyond that, this particular tool and its value for certain workflows was detailed. Lennart's use of it to test development versions of systemd on his host system is nice. Testing core system applications without risking making your system inoperable is useful. The explanation of future plans with using this to run containers from the host's /usr with systemd-nspawn makes sense. Not all containers should be remote-built docker images. Auto-discovery of images is good for centralized feature management. And signature verification is important - especially since, as a point of system extensibility, it's a new potential attack vector. There's a lot of potential for its use in purpose-built distros - as well as for helping advanced users get things done on extremely locked-down systems.

As usual, systemd isn't about adding ground-breaking functionality. It brings niche features into core, maintained system functionality and integrates them with other services in a distro-independent fashion using standardized paths and behavior. And honestly, if it were brand new functionality it'd be even more hate than situations like this where it's integrating more niche functionality.

Although, if you've got some Lennart hate to spare, please direct it at him for refusing to scrap his shitty spec-ignoring stateful tracking of DNS servers in systemd-resolved. Fucker still won't backpedal on that nonsense.

[edgmnt]

It might be quite useful to extend the idea and allow unprivileged users to get their own extended /usr, effectively adding per-user package management. But I suppose it's a can of worms to deal with setuid/setgid binaries and just about anything that crosses privilege boundaries (e.g. even 'sudo' might be tricked in more ways).

[NobodyXu]

It might be quite useful to extend the idea and allow unprivileged users to get their own extended /usr, effectively adding per-user package management. But I suppose it's a can of worms to deal with setuid/setgid binaries and just about anything that crosses privilege boundaries (e.g. even 'sudo' might be tricked in more ways).

What you are describing is effectively containers.

Unprivileged users cannot modify /user.
If they can, then the system can be easily compromised.

And yes, setuid is a problem for container.
Some escalations indeed from container roots from setuid binaries.