Hacker News new | past | comments | ask | show | jobs | submit login
Systemd Absorbs “su” Command Functionality (tlhp.cf)
43 points by jmount on Aug 29, 2015 | hide | past | web | favorite | 49 comments

Thank the deities for Theo de Raadt. Some consider him to be an asshole, but he's my kind of asshole!

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.

> 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.

You can't argue with Poettering. He writes technically superior solutions for extremely edge-case problems and then markets them fiercely, dismissing people as stupid if they prefer the caveman's way [e.g. UNIX]. To disagree is to say you prefer a kludgy unintelligent mess. Which, we do. But you don't win points in a feature-comparison pissing contest for that.

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?

> Theo is basically who Poettering would be if he forked Linux (and was less whiny).

These personal insults make it difficult for people to take the anti-systemd crowd seriously.

Torvalds could have been such an asshole for Linux, but he is adamant to not look outside of the kernel. As such, Poettering, Sievers, and the rest are doing an envelopment and containment move by basically building a second kernel in userspace. They also seem to have managed to get a friendly ear on the inside in the form of GregKH. A person that Torvalds seems to place a bit too much trust in these days.

> 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.

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.

It used to be I ran Linux and was unhappy that it didn't cover 100% of the functionality I could get in Windows. then they started approaching parity and I came to terms with not being able to do everything. Now I run OpenBSD on my laptop and it doesn't cover 100% of the functionality I could get in Linux (which was just reaching Parity with Windows for my uses.) But I already learned to be OK not being able to do every single thing. A generation comes and a generation goes, but the earth abides forever.

The actual article is here (it's linked in the /. page)


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.

The apologist's response is sometimes difficult to grok. Here, let me translate:

"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?"

Churn is often driven by emperor's new clothes, the feeling that change is automatically improvement and/or NIH-syndrome.

This comment is needlessly rude. Can you rephrase it in a way that makes sense and isn't insulting to anyone?

Flagged for personal insult.

It is ok that you do not understand the issues being dealt with here, you just have to say so.

Your comment is content-less. Based on it, I could say exactly the same to you.

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.

RE: "vs. doing the work to write a PAM module that behaves in the required manner." - That's easy, the functionality necessary to create a clean login in a container is beyond the scope of what PAM does.

Define clean login? I'm not aware of such a spec.

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.

In effect, something su was doing broke whatever infosec voodoo systemd was trying to do to keep track of "sessions".

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).

You see peterwwillis's reply to your comment? That's the sort of meaty discussion I was looking for. Your post -while better than your first- is the sort of content-light, platitude-heavy post that I most often see from folks who have taken a side in a tech holy war but are not otherwise really involved. [0] I would very much like to engage you in a real technical discussion. I'm eager to learn new things!

> [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.

I could say the same about your comments thus far.

Personal attacks are not allowed on Hacker News. Please don't do this here.

The parent of the comment you replied to is a personal attack.

When I ask someone to follow the guidelines, I'm not implying that they were the only person breaking them. It's physically impossible for us to read all the comments.

The rules apply regardless of whether someone else started it or was behaving worse. Otherwise everyone would have an excuse for everything, since it always feels like someone else started it.

I never implied the comment you replied to wasn't breaking the rules.

So? Does that somehow excuse your insult?

What insult?

Your inability to see that the pro-systemd side has actual reasons for holding its views makes you and the rest of the anti-systemd side ignorant and unable to discuss this on a sound footing without resorting to insults.

Lennart's basic premise for doing this is quite wrong. Not completely groundless, but still substantially wrong. He writes:

> [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".

The Freedesktop foundation is starting to scare me. I feel like all of their projects, in aggregate, are heading in a direction I do not know if I like.

Look into its history, it got fired up by Havoc Pennington out of RH. Sadly it seemed to work at first, but now it is basically a tool for Gnome/Fedora to bludgeon the rest into submission by sheer weight of code.

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.)"

Thank you for the link. This makes Freedesktop seem almost sinister.

I do believe it was started with the best of intentions (but the road to hell is paved with those and all that).

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.

Systemd is still hungry...


"systemd-machined" is systemd in name only. It's not like the init system has built in su functionality, this is just the project's container/vm manager getting some new functionality. This isn't a full replacement for su and it doesn't even come close to the functionality of sudo.

This comment is content-free.

Nah. Systemd started out as "just an init system". It has grown and grown since those days, ages ago.

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.)

[0] https://lwn.net/Articles/490413/

Gentoo started eudev in part because extracting udev from the larger systemd project became too cumbersome. Each time there was a update the process changed enough to break attempts at automation, apparently.

the Linux From Scratch team adopted eudev for their non-systemd edition ("classic") for a similar reason.

Yeah, I know. Due to inertia, I'm still using sys-fs/udev and will probably continue to do so until Sievers makes good on his implied threat.

i seem to recall that some interfaces had been moved from udev to libsystemd, or something, recently.

Then, perhaps the time for migration to eudev is nigh! :D

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".

Your comment was still content-free.

Your comment was a simple personal attack, and added nothing to the discussion. People can disagree with you without being stupid, you know, and not admitting that makes the anti-systemd side weak.


> please do us all a favour and shut up.

This comment breaks the HN guidelines. We ban accounts that do this repeatedly. Please follow the rules and only post civilly and substantively.



For whatever it's worth, he was clearly not posting substantively. Perhaps a reminder would be in order?

"machinectl" ? if the commands were actually sensibly named it would be less bothersome.

You can alias it to whatever you want, but the name is reasonable in context. machinectl is the interface to systemd-machined which is used to manage the host system, containers, and virtual machines in a consistent way.

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"

Why link to Slashdot? @dang, please fix this?

It's usually faster and more effective to send an email to hn@ycombinator.com .


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact