4 ms·
The actual article is here (it's linked in the /. page) https://tlhp.cf/lennart-poettering-su/ https://tlhp.cf/lennart-poettering-su/ As usual, it's a much mo
by Jedd 11y ago
The actual article is here (it's linked in the /. page)
https://tlhp.cf/lennart-poettering-su/ 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.
- peterwwillis 11y agoThe 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?"
- Thetawaves 11y agoIt is ok that you do not understand the issues being dealt with here, you just have to say so.
- simoncion 11y agoYour 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.
- Thetawaves 11y agoRE: "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.
- peterwwillis 11y agoDefine 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-support/ 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.
- dang 11y agoPersonal attacks are not allowed on Hacker News. Please don't do this here.
- cbd1984 11y agoThe parent of the comment you replied to is a personal attack.
- Twirrim 11y agoSo? Does that somehow excuse your insult?
- cbd1984 11y agoWhat insult?
- dang 11y agoWhen 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.
- cbd1984 11y agoI never implied the comment you replied to wasn't breaking the rules.
- bro-stick 11y agoChurn is often driven by emperor's new clothes, the feeling that change is automatically improvement and/or NIH-syndrome.
- cbd1984 11y agoFlagged for personal insult.
- cbd1984 11y agoThis comment is needlessly rude. Can you rephrase it in a way that makes sense and isn't insulting to anyone?
- cbd1984 11y agoYour 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.
- dang 11y agoOk, url changed from http://linux.slashdot.org/story/15/08/29/1526217/systemd-absorbs-su-command-functionality http://linux.slashdot.org/story/15/08/29/1526217/systemd-abs....