Systemd Absorbs “su” Command Functionality
tlhp.cf
tlhp.cf
I love OpenBSD. I know it's too limited to be for everyone, but it suits my purposes quite well. And I can confidently assert that, for as long as Theo is the not-so-benevolent dictator for life, that OpenBSD will never have anything as messy and complex as systemd.
What I don't understand is how the vast majority of the Linux community is not just allowing, but encouraging, systemd to continue to grow without bound.
The vast majority of the Linux community has no influence on the development of systemd and its cloud of closely related software. What's more, Poettering & co. are notoriously opinionated and bullheaded. This makes attempts to steer "their" projects in new directions all but impossible.
If Debian had moved from SysV init to -say- OpenRC, systemd would be a strictly RedHat curiosity. [0] If my experience with Kubuntu 15.04 is typical [1], we might see some pushback from -at a minimum- Canonical.
The Linux kernel hackers asked some serious technical questions about kdbus (another Poettering Cabal project) back during the 4.1 merge window. The answers that they got back were less than satisfying. I haven't been following the kdbus project closely since then, but AIUI, the objections raised have yet to be addressed.
[0] It's a pity that that conversation was not on my radar when it first started; I would have loved to get up to speed on OpenRC and attempt to address the Debian folks' concerns with it!
[1] Systemd boot times are 2->10x slower than boot times with Upstart (and the systemd boot time reporting software provides incorrect numbers), and systemd system shutdowns occasionally hang forever, requiring the use of SysRq key combos to kill the machine.
Theo is basically who Poettering would be if he forked Linux (and was less whiny). He probably hasn't because it would be a ton of work and few people would use it, and he couldn't benefit from the base of support of the Linux ecosystem. There's a lot of crap out there that's Linux-only now, or officially only supports certain distros. It makes much more sense to convince someone to shoehorn your code into their distro than to make your own.
Few desktop users ever notice it, most server admins aren't really that knowledgeable, and most devs just write userland code. I think most people don't think about how much more of a headache things have become. After all, hasn't Linux/UNIX always been a headache, relatively speaking?
These personal insults make it difficult for people to take the anti-systemd crowd seriously.
Red Hat revenue FY2015: $1.79 billion
They can allocate developers to systemd far, far beyond the capability for any other Linux organisation or group who might be developing an alternative approach.
Basically steamrollering systemd into the GNU / Linux environment.
https://tlhp.cf/lennart-poettering-su/
As usual, it's a much more reasoned, moderate, thoughtful, and cautious response to a deeper issue than just 'trying to take over the whole operating system'.
IIUC, there's no suggestion to deprecate su, but to provide a more predictable rights elevation (which includes flipping to a different or less privileged uid/gid) using an additional feature that's implemented in one of the systemd components.
"Really guys, it's obvious he's not trying to take over the operating system. He's only saying it's full of flawed obsolete technology which in some technical or user-specific way doesn't make sense, so he's going to replace it all piece by piece until it's eventually impossible to recognize the operating system as 'Linux', or even UNIX-like. It's just a gradual conversion into a completely different OS, not a takeover at all. What's the big deal?"
The discussion would benefit if you would take the time to post a new comment with a meaty discussion of the technical merits of rolling this into systemd vs. doing the work to write a PAM module that behaves in the required manner.
Bonus points if you can point out how this su replacement comports with the systemd proponents' continual refrain that "All parts of systemd that live outside of PID 1 are optional; you don't have to use them!". :)
I look forward to your post! Heated, substance-less discussions are tiresome.
In fact, the author of the change, Lennart Poettering, says nothing about wanting to have a login, much less a 'clean' one. They have login functionality already. He only mentions that the way su provides the user a shell as the super-user is 'very unclear' and 'weakly defined', and thus the tool has a 'broken concept'.
The reason this was even written was a bug that systemd introduced. As i'm sure you're well aware, $XDG_RUNTIME_DIR is an environment variable used by the XDG base directory specification to specify a directory that the user's applications can write state to, and is destroyed on termination of the session. The pam_systemd plugin apparently fails to do this because it tries to create a new session when they're already running in a session.
Oh hey, look. There's a PAM module that handles setting this variable, too. https://apps.ubuntu.com/cat/applications/raring/libpam-xdg-s...
As i'm also sure you're aware, 'su' is not intended to be a login program. That's what login is for. What Poettering was confused about is defined by the source code for su, in su-common.c of util-linux:
"Run a shell with the real and effective UID and GID and groups of USER, default `root'."
And that seems to be what 'su' does. Hmm.... yeah, this is definitely a very unclear and weakly defined concept. I can see now why Poettering had to implement a new tool for systemd to fix a bug with pamd_systemd not being able to create a session, and the user not knowing how to use the xdg-support pam plugin. Stupid UNIX!
As to another user's comment about how 'su' works: if you use it without the login-simulation feature, it only changes HOME and SHELL (and USER and LOGNAME if not becoming superuser). With login-simulation, it changes HOME, SHELL, USER, LOGNAME, PATH, leaves TERM alone, and deletes all other environment variables.
This is seen as a bug, which I can understand, if you're running 'su' in a complicated new system with new features which need special care to support. In such a case one would normally patch the application to include support and not reinvent the wheel, but that requires working with other people, which isn't really systemd's strong suit.
Part of this was what path that xdg variable got set to, so in their infinite visdom the systemd devs decided to clear it whenever su was run.
This in turn lead to various programs curbstomping user files as root (in particular Gnome ones, surprise surprise).
At this point in time it seems like one would do best to stay well away from anything related to Systemd, Gnome, Freedesktop and Fedora. The mixing of roles in those groups is downright worrying (i wonder how many times i have seen someone use a Gnome blog to port straight RH/Fedora news, even though the latter surely has their own blogging facilities).
> [T]he functionality necessary to create a clean login in a container is beyond the scope of what PAM does.
Given that I use a PAM module that takes the login password that I keyed in, calls out to cryptsetup using that password to unlock an encrypted volume, creates the mountpoint for that volume, mounts it, then -when I've logged out- (optionally) kills any processes of mine that may still be running, then reverses those mount and unlock operations, I'm not convinced that your claim is true.
Please convince me otherwise! :D
[0] Why is it the most frequent? I don't know for sure, but I suspect that the adage "It's easy to have opinions, but much harder to have informed opinions." would be applicable.
The rules apply regardless of whether someone else started it or did worse. Otherwise everyone would have an excuse for everything, since it always feels like someone else started it.
> [su] will given you kind of a shell, and it’s fine to use it for that, but it’s not a full login, and shouldn’t be mistaken for one.
Well, yes, by default. But... that's what "su -" is for. Gives you new root shell as a treat, complete with env clean-up and running root's preferred shell interpreter.
Granted, having to type two extra characters each time is mildly annoying, but hardly a good reason to produce grand claims like "su is really a broken concept".
Frankly it seems that Linux has grown its own "internal" MS. A massive, overfed gorilla in the form of Red Hat. And it is now swinging its weight around, thinking it has "won" some kind of unix war. Sadly it may well be right, as there is few that can match it in the amount of man hours it can throw at a project.
Damn it, https://github.com/subuser-security/subuser/issues/216 is a "blog" entry related to Docker that holds a mention of such weight throwing.
"A number of developers from RedHat were once very involved in the project. However, these developers had a very arrogant attitude towards Docker: They wanted docker changed so that it would follow their design ideas for RHEL and systemd. They often made pull requests with poorly written and undocumented code and then they became very agressive when those pull requests were not accepted, saying "we need this change we will ship a patched version of Docker and cause you problems on RHEL if you don't make this change in master." They were arogant and agressive, when at the same time, they had the choice of working with the Docker developers and writting quality code that could actually be merged. Another thing they often said was along the lines of "systemd is THE ONE AND ONLY INIT SYSTEM so why do you care about writing code that might be portable?" Or "even though the universal method works with systemd now. A redesign has already been planned in systemd, so do it the new systemd way and don't be portable."(This is in response to the fact that Docker writes to cgroups, and systemd would like to be the "sole writter to cgroups" some time in the future.)"
Its just that one party involved in all this has better lines of communications, more funding, and apparently a fervent belief that their solution is always the right one.
End result is something of a unconscious steamrolling of everyone else.
One day, systemd will eat udev:
Kay Sievers on Tue, 3 Apr 2012:
"After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly." [0]
(Emphasis mine.)
the Linux From Scratch team adopted eudev for their non-systemd edition ("classic") for a similar reason.
I haven't followed the udev saga in a very long time. I do know that I have =sys-fs/udev-224-r2 installed and I don't have systemd installed. I also don't have any executable files on my system named "systemd".
I've got a bunch of RHEL systems at work and I've just aliased all the -ctl commands.
If you want to open a shell on a container you would run "machinectl shell my-container-1"