Lennart Poettering's long story short: "`su` is really a broken concept
Declaring established concepts as broken so you can "fix" them.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux. You need a shell with some commands to be run with additional privileges in the original user's context.
If you need a full login you invoke 'su -' or 'sudo bash -'
Deciding what a full login comprises is the shell's responsibility, not your init system's job.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux.
You're pretty much making an argument to tradition here. The correct thing to do would be to counter his claims:
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 weak
ok, I just spent my morning researching the problem, and why the feature got built, starting from here [github.com] (linked to in the article). Essentially, the timeline goes like this:
1) On Linux, the su command uses PAM to manage logins (that's probably ok).
2) systemd wrote their own version of PAM (because containers)
3) Unlike normal su, the systemd-pam su doesn't transfer over all environment variables, which led to:
4) A bug filed by a user, that the XDG_RUNTIME_DIR variable wasn't being maintained when su was run.
5) Lennart said that's because su is confusing, and he wouldn't fix it.
6) The user asked for a feature request to be added to machinectl, that would retain that environment variable
7) Lennart said, "sure, no problem." (Which shows why systemd is gaining usage, when people want a feature, he adds it)
It's important to note that there isn't a conspiracy here to destroy su. The process would more accurately be called "design by feature accretion," which doesn't really make you feel better, but it's not malice.
Sometimes su is confusing, I've been using it for many years, yet it has never been clear to me which variables get passed over to the root session ans which do not, to the point that sometimes I do ssh root@localhost instead of su, just to be sure.
If you're having that kind of difficulty, just change to a CLI console and log in as root. If you need to check something in a different window, you can always go back to X (or Wayland, if appropriate) for a moment.
yet it has never been clear to me which variables get passed over to the root session ans which do not
All exported environment variables, just as if you started a spawned a shell binary with the same user.
Except on systems that implemented PAM su, on these systems, PAM modules might be used to change
the values of ulimits or some other environment variables, or clear some.
They might do this because it is the desire of whoever configured the system to assign additional characteristics to
certain inte
if it confuses you so much and it actually matters to you a command such as "env" in each case gives you the practical difference (ie. nothing in nearly every case as far as shells go).
As one highly suspect of systemd, I find it really interesting that your audit of systemd has led to posts in which you are compelled to argue that systemd isn't wrong.
tbh, I do think Poettering is a good programmer, you probably have to be good to commit to the Linux kernel, and I would be happy to have him on my team. He has problems, but so do we all. The main issue I see with his code designs is that he doesn't have a good understanding of interfaces, which I tried to write about here [slashdot.org].
Some people want to push him out of the open source community, but I think that would be a horrible shame. He's such an enthusiastic contributor, I think if he just fixed a few of hi
I read and completely agree with your article about interfaces. I'd rank that principle a close second to KISS (keep it simple....) in terms of its absolute necessity in terms of managing the complexity inherent in all modern systems. But, sadly, I believe Mr. Poettering fails to grasp either one. I don't doubt that he's a good and talented coder, or even that there are streaks of brilliance in his vision for how things could and should work. However, IMO, he demonstrates very little grasp of maintainab
Definitely interesting. I find that 90% or more of the legacy code I work on would fail any reasonable test of software quality, but, then, much of it was written by people whose background consisted largely of Visual Basic, and/or were mostly hardware, not software, specialists. I only wish it were easier to convey to top management why it is so vital to manage, or even to acknowledge, the resulting technical debt. Until a large customer complains, they just never seem to get the message, and, by the ti
Lennart said that it wasn't clear what su should do in this situation. Actually, it's quite clear. su - must construct an environment containing only TERM, HOME, SHELL, USER, LOGNAME, and PATH. That's been the case since UNIX SVR4, at the latest.
Yeah, that's true, I missed the - in the bug report. I don't know what that user was complaining about.
Bullshit (Score:5, Insightful)
Lennart Poettering's long story short: "`su` is really a broken concept
Declaring established concepts as broken so you can "fix" them.
Su is not a broken concept; it's a long well-established fundamental of BSD Unix/Linux. You need a shell with some commands to be run with additional privileges in the original user's context.
If you need a full login you invoke 'su -' or 'sudo bash -'
Deciding what a full login comprises is the shell's responsibility, not your init system's job.
Re: (Score:4, Insightful)
You're pretty much making an argument to tradition here. The correct thing to do would be to counter his claims:
Re:Bullshit (Score:5, Interesting)
1) On Linux, the su command uses PAM to manage logins (that's probably ok).
2) systemd wrote their own version of PAM (because containers)
3) Unlike normal su, the systemd-pam su doesn't transfer over all environment variables, which led to:
4) A bug filed by a user, that the XDG_RUNTIME_DIR variable wasn't being maintained when su was run.
5) Lennart said that's because su is confusing, and he wouldn't fix it.
6) The user asked for a feature request to be added to machinectl, that would retain that environment variable
7) Lennart said, "sure, no problem." (Which shows why systemd is gaining usage, when people want a feature, he adds it)
It's important to note that there isn't a conspiracy here to destroy su. The process would more accurately be called "design by feature accretion," which doesn't really make you feel better, but it's not malice.
Re:Bullshit (Score:5, Insightful)
The problem is at step 5): su isn't confusing. It's a lame excuse to get your way.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
yet it has never been clear to me which variables get passed over to the root session ans which do not
All exported environment variables, just as if you started a spawned a shell binary with the same user.
Except on systems that implemented PAM su, on these systems, PAM modules might be used to change the values of ulimits or some other environment variables, or clear some.
They might do this because it is the desire of whoever configured the system to assign additional characteristics to certain inte
Re: (Score:2)
Re: (Score:2)
Provide an environment similar to what the user would expect had the user logged in directly.
The problem with the man page os "su" is that "similar" and "expect" mean nothing.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Wow...that is .. fightning. I dont' understand why I'm using this command incorrectly and abusing it, so could you add a crappy workaround.
I do think systemv init scripts needed to replaced and I'm for full-process control...but systemd is a horrible implemention of that.
Re: (Score:3)
I've found another way how to avoid the problem: no PAM at my Slackware machine. See? The rest of the list is, all of a sudden, pointless.
Re: (Score:2)
As one highly suspect of systemd, I find it really interesting that your audit of systemd has led to posts in which you are compelled to argue that systemd isn't wrong.
Re: (Score:2)
Re: (Score:2)
Posts today (yesterday). Just seems like you've gained insight, and I value your opinion.
Re: (Score:2)
Re: (Score:2)
Some people want to push him out of the open source community, but I think that would be a horrible shame. He's such an enthusiastic contributor, I think if he just fixed a few of hi
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
The bug report was that XDG_RUNTIME_DIR was cleared when su was run in "login" mode, not when it was run in environment-preserving mode.
pam_systemd correctly preserves XDG_RUNTIME_DIR when it is run in environment-preserving mode.
When run in login mode - where su's manpage says leads to an environment which inherits only TERM - it doesn't inherit XDG_RUNTIME_DIR.
Lennart said that it wasn't clear what su should do in this situation. Actually, it's quite clear. su - must construct an environment contain
Re: (Score:2)
Lennart said that it wasn't clear what su should do in this situation. Actually, it's quite clear. su - must construct an environment containing only TERM, HOME, SHELL, USER, LOGNAME, and PATH. That's been the case since UNIX SVR4, at the latest.
Yeah, that's true, I missed the - in the bug report. I don't know what that user was complaining about.
Re: (Score:2)
malice schmalice - If a hobbyest can push crap to the many (professionals), the framework is flawed.
He's a professional, he works for RedHat.