Slashdot Mirror
Systemd Absorbs "su" Command Functionality
jones_supa writes: With a pull request systemd now supports a su command functional and can create privileged sessions that are fully isolated from the original session. The su command is seen as bad because what it is supposed to do is ambiguous. On one hand it's supposed to open a new session and change a number of execution context parameters, and on the other it's supposed to inherit a lot concepts from the originating session. Lennart Poettering's 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." The replacement command provided by systemd is machinectl shell.
If you want a FULL shell
Oh I dont know 'su bash' usually works pretty fng good...
It does if you are fine to only get root privilege, without FULL environment of root. But if you would have to make sure you have FULL root environment, first discarding anything you had in calling user and then executing root users environment (/etc/profile etc.) you better use "su - bash" or "sudo -i". Compare what you get both ways "su bash" vs "su - bash" with runnint "set" and "env" commands, please.
Failing to have FULL root environment, can have security implications (umask, wrong path, wrong path order, ...) which may or may not be critical depending what system you are operating and to whom. Also some commands may fail or misbehave just because of path differences etc.
Above is trivial information and should be clear without further explanation anyone running *nix systems for someone else as part of job ie. work professionally on the field. Incase you don't, it's still useful information you should learn about sysadmin of the platform you happen to use.
I've had a job now for about 10 years where a large fraction of the time I wear a software engineer's hat. Looking back now, I can point to a lot of design decisions in the software I work on that made me go "WTF?" when I first saw them as a young'un, but after having to contend with them for a good number of years, and thinking about how I would do them differently, I've come to the conclusion that the original WTF may be ugly and could use some polish, but the decisionmaking that produced it was fundamentally sound.
The more I hear about LP and systemd, the more it screams out that this guy just hasn't worked with Unix and Linux long enough to understand what it's used for and why it's built the way it is. His pronouncements just sound to me like an echo of my younger, stupider, self (and I just turned 30), and I can't take any of his output seriously. I really hope a critical mass of people are of the same mind with me and this guy can be made to redirect his energies somewhere where it doesn't fuck it up for the rest of us.
"su command is seen as bad because what it is supposed to do is ambiguous. "
-- end quote --
it is NOT ambiguous!!!!!
"su" is root BUT!!! with the normal users $PATH and settings
"su - " and "su -l root "
IS THE ROOT USER
there is NOTHING ambiguous there at all
now what Ubuntu did to "sudo"
THAT!!! is a problem
"I don't pitch OpenSUSE Linux to my friends, i let Microsoft do it for me
sense anyway). By "fully isolated", it sounds like machinectl breaks the audit trail that su has always supported (not being 'fully isolated' by design). Many *NIX systems are configured to prohibit root logins from anything other than the system console. And the reason that su doesn't do a 'full login' either as root or another user is to maintain the audit trail of who (which system user) is actually running what.
Lennart, this UNIX/Linus stuff appears to be way over your head. Sure, it seems neat for lots of gamers who can't be bothered with security and just want all the machine cycles for rendering FPS games. Perhaps you'd be better off playing with an XBox.
Have gnu, will travel.
ok, I just spent my morning researching the problem, and why the feature got built, starting from here (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.
"First they came for the slanderers and i said nothing."
I can't speak for any distribution, after quitting as a Debian developer some months back, for several reasons one of which was systemd. But speaking for myself, it was quite clear during the several years of "debate" (i.e. flamewars) over systemd that this was the inevitable outcome. The debate over replacing the "init system" was a complete red herring; systemd knows no boundaries and continues to expand its tentacles over the system as it subsumes more and more components. My problem with this is that once a distribution has adopted systemd, they have to basically just accept whatever crap is shovelled out in the subsequent systemd releases--it's all or nothing and once you're on the train you can't get off it. This was absolutely obvious years ago. Quality software engineering and a solid base system walked out of the door when systemd arrived; I certainly did.
When I commit to a system such as a Linux distribution like Debian, I'm making an investment of my time and effort to use it. I do want to be able to rely on future releases being sane and not too radical a departure from previous releases--I am after all basing my work and livelihood upon it. With systemd, I don't know what I'm going to get with future versions and being able to rely on the distribution being usable and reliable in the future is now an unknown. That's why I got off this particular train before the jessie release. After 18 years, that wasn't an easy decision to make, but I still think it was the right one. And yes, I'm one of the people who moved to FreeBSD. Not because I wanted to move from Debian after having invested so much into it personally, but because I was forced to by this stupidity. And FreeBSD is a good solid dose of sanity.