SoylentNews is people
SoylentNews
The Linux Homefront Project reports on Lennart Poettering looking to do away with the good old "su" command. From the article, "With this pull request systemd now support a su command functional and can create privileged sessions, that are fully isolated from the original session. Su is a classic UNIX command and used more than 30 years. Why su is bad? Lennart Poettering says:"
Well, there have been long discussions about this, but the problem is that what su is supposed to do is very unclear. On one hand it’s supposed to open a new session and change a number of execution context parameters (uid, gid, env, …), and on the other it’s supposed to inherit a lot concepts from the originating session (tty, cgroup, audit, …). Since this is so weakly defined it’s a really weird mix&match of old and new paramters. To keep this somewhat managable we decided to only switch the absolute minimum over, and that excludes XDG_RUNTIME_DIR, specifically because XDG_RUNTIME_DIR is actually bound to the session/audit runtime and those we do not transition. Instead we simply unset it.
Long story short: su is really a broken concept. It 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.
I'm guessing that Devuan won't be getting rid of "su."
(Score: 1) by Eunuchswear on Tuesday September 01 2015, @01:44PM
And if you read the original bug report [github.com] you'll find that that doesn't work -- "su - root" does not give the same environment as logging in as root (the XDG_RUNTIME_DIR environment variable is not set up).
Poettering, correctly, refused to modify the behaviour of su (it does what it the man page says it should) and provided a new command to do what the users wanted done.
Because everyone "knows" that systemd developers always reply WONTFIX to bug reports, right?
Watch this Heartland Institute video [youtube.com]
(Score: 3, Insightful) by linuxrocks123 on Tuesday September 01 2015, @06:50PM
XDG_ORIFICE_EXCRETA didn't even exist until about 30 years after su was coded, so its behavior regarding that nonsense couldn't have been part of its original documentation. If Red Hat changed its behavior, the bug is theirs, not su's. All my Slackware man page for su says is that su - should "provide an environment similar to what the user would expect had the user logged in directly." It appears to do that in Slackware, although I did have an XDG_SESSION_COOKIE variable in my login shell that was not in my "su -" shell. Uninstalling the third-party PAM crap I'd inflicted upon my system at one point to try out otpw fixed that by getting rid of XDG_SESSION_COOKIE entirely. Still not sure how or why PAM wanted to give me an XDG cookie.
(Score: 1) by Eunuchswear on Wednesday September 02 2015, @09:43AM
So you'd rather they changed the way su worked.
Why am I guessing you'd have bitched about that if they did?
Watch this Heartland Institute video [youtube.com]
(Score: 2) by linuxrocks123 on Wednesday September 02 2015, @10:04AM
Whatever problem they are having is a Red Hat distro-specific issue, not a general issue with the su command, since the issue does not exist in Slackware. Creating a new command in a distro-agnostic software system like systemd to solve a parochial problem like that is inappropriate.
Since they appear to have painted themselves into a corner by introducing a bug in their su behavior that their customers came to rely on, most likely they should have just patched su with a new flag indicating "no, really, give me a new session, not the old buggy behavior" and been done with it.
(Score: 0) by Anonymous Coward on Wednesday September 02 2015, @02:48PM
What is Systemd is not distro-agnostic, but distro-mutating? Meaning that every distro that adopts systemd ends up mutating into some RHEL/Fedora clone?
(Score: 1, Informative) by Anonymous Coward on Thursday September 03 2015, @03:35PM
The reason that variable was not set was because of a certain systemd pam module.
Because apparently setting it to the proper dir (as was done before systemd, iirc) would break their session tracking voodoo.
Ergo, su didn't break anything. Poettering's systemd basically created a strawman situation that allowed Poettering to poo poo all over some very tested by time unix functionality.