Given Lennart already declared SUID concept as “bad”, I think this is the game plan all along.
Systemd: Do all the things, but not very well, and don’t listen to anyone.
Focusing all of this to sudo and framing SUID as “just implemented to enable sudo” is not painting the correct picture.
Moreover, removing SUID breaks tons of mechanisms and scenarios.
Security of sudo can be debated, but evolving current sudo to a better state step by step is miles better than banishing and rebuilding it and making it dependent on systemd + polkit. systemd already breaks tons of UNIX conventions and way more complicated than it should be.
When you think, it sounds like “conquering” another part of user space mixed with NIH (and we know the best), and making systemd more entrenched. systemd is already a pretty large surface area to attack to begin with.
XZ back door reached SSHd over libaystemd. Do we need another “integrated target” to attack in Linux?
I can see how the original authors didn't consider these cases, because they simply weren't there yet... but knowing what we know today: SUID is an awful idea.
If you access and run, it’s SSH or similar, so it works on the system scope. If it’s a container built correctly, it has its own users and isolation already, so it shouldn’t be able to fire any binary on your “base” system, and any effect is already in the container scope.
I have never had the need to SUID/GUID a non executable, and didn’t need to trigger something on the system inside a container in the last ~20 years.
A lot of publicly available container images require elevated permissions to simply function, not for anything extraordinary. So, the user in container needs to be a superuser. It's often even not to perform the program's main function, but because various ordinary things in Linux require elevated permissions.
> container built correctly
That's a spherical horse in vacuum. If you write code s.t. there aren't any errors, you don't need to do error handling, right? You don't get to choose how containers are built. You need to deal with all possibilities of how containers can be built.
Network filesystem? -- /usr/shared, /usr/opt and /usr/local? That's by design... very typical for cluster management software to mount these from NAS. It's also very not typical to keep these as "only text files". Pretty sure a lot of Google's stuff installs automatically into /usr/shared. I think even Go compiler and other infra at some point was being installed there by default.
Finally: the same argument as with containers. You, for some reason, are trying to fantasize the world where problems don't exist because you chose the world w/o problems. But this isn't the real world. It's a fantasy. In real world, with or without reason, programmers and other computer users will do what's possible, not what you want them to do.
SUID, like any system, is flawed. Most of those flaws are balanced trade-offs; if you're addressing one you need to be aware of the severity of any counter-problems you're inevitably introducing.
Lennart is well known for criticising existing systems while simultaneously ignoring & dismissing criticism of the proposed solutions - you need to be able to weigh up both sides in a balanced way. Lennart demonstrably isn't.
That's why nobody uses his software. I mean just nothing he does gets adopted.
The 'run0' solution uses an already existing mechanism that is already used for a lot of things.
Yes, you're absolutely right. Popularity is the best indicator of quality.
Specially since we are talking about free software, and not some software that Microsoft can preinstall on your laptop.
Pulse has been replaced with the pipewire as soon as it arrived, for example.
> Pulse has been replaced with the pipewire as soon as it arrived
Pipewire combines alsa, pulse and jack. They all have different strength.
And Pulse was started by Lennard but he hasn't been involved for a very long time.
Well, I was a tech lead of a Debian derivative when Debian held the vote. I have seen and read enough. Didn't see the other "threats" thing, but since I had access to debian-devel, I was in the middle of it.
My views about systemd has not changed since then, and can be found if you search HN.
On the other hand, I have used 4-5 init systems in the last 20 years, and none of them were that aggressive and had the "we know the best" attitude, while going against all the best practices and making the same mistakes done in the past.
> Pipewire combines alsa, pulse and jack. They all have different strength.
Nope. ALSA is always there, working as the primary sink, delineating user space and hardware. I used Jack back in the day for recording, and never got to like pulse because of its backwards defaults and lassies-faire behavior about multi-channel audio (plus glitches, etc).
Pipewire is a great sound server which sits on top of ALSA, and replaces Pulse transparently, and makes everything 100x nicer along the way.
Lastly, it's Lennart Pottering. Not Lennard. :)
P.S.: It's important to understand that my views are not against the persons, but the behavior of the projects. I'd drink a nice round of beer with all of them, if I had the chance. :)
Nobody forced Debian. I followed it live too. I remember him talking to Debian and he made a technical argument for it.
I had already switched to Arch and had already been using Systemd for years at that point.
The reality is, nobody was stepping up with better solutions. Would porting SMF have been better, maybe, but nobody was porting that.
There are distros with Systemd, often very compatible ones, and almost nobody uses them.
BSD folks for years have been hoping for the linux exodus over systemd and it has never happen.
And it has to be said a 1000x times. Systemd was never just init and it mever claimed it was. By now Systemd is just a software project that makes all kind of software that you can use with or without systemd the service manager.
The should just call it the "Linux Userland Software Group" and change their naming. Then people wouldnt get triggered by the term 'systemd'.
You can have whatever technical opinion you like about systemd. Fact is most people use it, including in very large organisations. And the other fact is nobody forced systemd on Debian. Whatever consipiricy was apread in 'Devel' (and elsewhere).
I'll agree to disagree on the systemd's "we will replace anything and everything we even slightly dislike, and slowly make them dependent on systemd (the service manager) while not listening to you and your pesky experiences" attitude, and wish you more power for your future endeavors.
Have a nice day. :)
The problem is that the user controls the program's view of the filesystem, environment variables, and other attributes, and this is an attack surface that can be used to trick it into loading and running code provided by the unprivileged user, which runs as root. For example, ordinary programs have a preamble inserted by the compiler where they load a programming-language runtime, usually from somewhere like /usr/lib; but a setuid program can't safely do this, because the user could use a chroot to replace /usr/lib with something different.
In practice, this means that writing a setuid program correctly is exceptionally difficult and error prone, can only be done in C, and imposes security requirements on the compiler flags/makefiles rather than the source code, which creates a large risk of distro- or compiler-specific vulnerabilities. In practice, sudo is the only program people allow to use the setuid mechanism, and sudo is a unique and dangerous snowflake.
You need to be root in the first place to be able to do that