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.
I'm alright with commands that have longer names. It's harder to mis-type and execute the wrong thing, and it's easier to know what is going on at a glance.
Same thing when reading code. I'd much rather work with code that has a method named getUserByGuid(), for example, than gubg().
Besides, nothing prevents you from aliasing the longer commands to something shorter if you so choose.
There's a lot of things about systemd that turn me off, but commands with longer, more verbose names is not one of those things.
Love sees no species.
Poettering is so very wrong on many things, having a superficial and shallow understanding of why Unix is designed the way it is. He is just a hobbyist, not a hardened sys admin with years of experience. It's almost time to throw popular Linux distros in the garbage can and just go to BSD
No offense, but I see lots of attacks like this on systemd. Can you explain how it is "likely a new security threat" or is it simply FUD?
So systemd has ambition of being a container and VM management infrastucture (I have no idea how this should make sense for VMs though.)
machinectl shell looks to be designed to be some way to attach to a container environment with an interactive shell, without said container needing to do anything to provide such a way in. While they were at the task of doing that not too terribly unreasonable thing, they did the same function for what they call '.host', essentially meaning they can use the same syntax for current container context as guest contexts. A bit superfluous, but so trivial as not to raise any additional eyebrows (at least until Lennart did his usual thing and stated one of the most straightforward, least troublesome parts of UNIX is hopelessly broken and the world desperately needed his precious answer). In short, systemd can have their little 'su' so long as no one proposes removal of su or sudo or making them wrappers over the new and 'improved' systemd behavior.
Funnily enough, they used sudo in the article talking about how awesome an idea this is... I am amused.
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
.
systemd is on the way to turning a sleek, efficient Linux distribution into one loaded with awesome bloatware.
And it looks like there is no stopping Poettering's ego now that it's been unleashed.
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 tried a bunch of them a few years ago. I found that FreeBSD was the best one, even though it doesn't come with a GUI by default, and so you have to install it afterwards. (Seems kind of ridiculous to me, but that's how they package it for some reason.) I don't know if they've changed the documentation since then, but note that you don't have to compile X11 and your window manager, as there is a system that can install pre-compiled packages that they don't bother to mention until after they tell you how to compile your own packages. Just skip ahead in the manual to find it.
Overall, I really liked FreeBSD, as I found it much more agreeable to how I think things should work. What ultimately drove me away from it was sort of what ultimately drives people who use Linux back to Windows: familiarity. For example, I once needed to use "strace," but FreeBSD has "dtrace" instead, and while I could find many web pages insisting that dtrace was better than strace, for some reason none of those web pages could tell me how to make the much more advanced dtrace perform the comparatively simple task that strace performs, simply printing system calls and their parameters to stdout. So I switched over to Linux for that little project. After a while, I found myself switching over to Linux for a lot of things, just to get shit done rather than spend all day learning how to do it, and so I realized I might as well be using Linux to begin with.
I do plan to give it another go some day when I have a lot more time to spend learning it, as I really did like what I saw when I was using it, but it's just a simple fact that I don't use my computer for fun, and I can do stuff faster in Linux, not because it has better documentation, but because I've already wasted a lot of effort learning to use Linux and so dealing with its bullshit is easier than learning how to use FreeBSD's lack of bullshit.
"... Where the youngin's come in and rip up everything ..."
Get off my lawn and learn to spell.
I've run an IT *company* now for well over 15 years. Herr P is a bit outspoken but in general I agree with his approach. Some of their design decisions are a bit wacky to my mind but I'm an old fogey in that regard. However I am happy to report that my large herds of Linux boxes are much happier with systemd than they were with an unholy mix of sysvinit, openrc, upstart and other stuff.
Putting the imperative in the middle eg "systemctl restart apache2" is their biggest crime. SVO is all very well but in general you want to edit the verb. Funnily enough German generally uses a SOV construction.
Cheers
Jon
Subject Object Verb
You haven't been paying attention these last 20 years when every unix vendor has replaced SysV init with something else.
Writing init scripts is not a one time annoyance, at least not for distro maintainers. They are also not portable between distributions, as systemd unit files are. SysV init is also literally the dumbest form of init, where the init process has no information about dependencies, and cannot react sensibly to any changes in system state. Another sticking point involved the inability of the system to track processes accurately, which resulted in a number of kernel-level features over the years, of which cgroups are merely the most recent. Yes, it's fairly rare to have things go wrong, but pidfiles are unquestionably a bad hack.
Init is a misnomer. It was supposed to be the method by which your system changed states, but it was never very good at this, so people are used to thinking of it only as handling a few rare circumstances. The problem systemd solves is how to get the computer from state A to state B reliably, and guarantee that the services it manages are started properly. Startup and shutdown are special cases of this problem. It is built on kernel-level features that allow it to track processes accurately (and incidentally also track resource useage).
Systemd is the result of a number of (IMO) obvious choices. Cgroups exist, therefore it makes sense to write a service management tool to take advantage of them. As long as you're writing a service management tool, you should probably write in dependency resolution. Handling startup and shutdown is another logical choice. Also, since 95% of init script contents are common tasks, it makes sense to abstract out that stuff into a common C-based library. At this point it is relevant to note that, cgroups aside, OpenRC does this exact same thing.
Writing scripts is part of UNIX, and systemd coexists with them pretty happily. However, rewriting scripts into more flexible C libraries is also part of the UNIX tradition. What's so hot about these scripts, besides that you're more comfortable working with them?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.