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.
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 apt-get remove systemd --purge
Great to see that systemd is finally doing something about all of those cryptic command names that plague the unix ecosystem.
Upcoming systemd re-implementations of standard utilities:
ls to be replaced by filectl directory contents [pathname]
grep to be replaced by datactl file contents search [plaintext] (note: regexp no longer supported as it's ambiguous)
gimp to be replaced by imagectl open file filename draw box [x1,y1,x2,y2] draw line [x1,y1,x2,y2]...
I know systemd sneers at the old Unix convention of keeping it simple, keeping it separate, but that's not the only convention they spit on. God intended Unix (Linux) commands to be cryptic things 2-4 letters long (like "su", for example). Not "systemctl", "machinectl", "journalctl", etc. Might as well just give everything a 47-character long multi-word command like the old Apple commando shell did.
Seriously, though, when you're banging through system commands all day long, it gets old and their choices aren't especially friendly to tab completion. On top of which why is "machinectl" a shell and not some sort of hardware function? They should have just named the bloody thing command.com.
Well, let me explain some of the problems that I've had with su.
Oh wait. I've never had problems with su. Ever. What is up with this???
Doing everything as systemd do, and adding 'su', is likely a new security threat.
How long until systemd absorbs emacs?
.
You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away.
-- Antoine de Saint-Exupery
I, for one, welcome this addition... every privilege escalation path you add is good for literally years of paid contract work.
machinectl shell is only incidentally similar to su. Its primary purpose is to establish an su-like session on a different container or VM. Systemd refers to these as 'machines', hence the name machinectl.
http://www.freedesktop.org/sof...
su cannot and does not do that sort of thing. machinectl shell is more like a variant of rsh than a replacement for su.
That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.
Where 'modernize' is a codeword for 'shit all over'.
That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.
Yeah, that's true. He sees features people want, and he builds them. For example, Debian distro builders were frustrated writing init scripts, so Poettering made something that filled the need of those distro builders. That's why it got adopted, because it contained features they wanted.
The problem of course is that he doesn't understand the Unix way, especially when it comes to good interfaces between code (IMNSHO).
The people who like systemd tend to like the features.......the people who dislike it, the architecture.
"First they came for the slanderers and i said nothing."
I am really tired of systemd. So really tired of the developers shoving that shit down the linux throat. It's not pretty, it seems to grow out of control, taking on more and more responsibility .... I don't even have an idea how to look at my logs anymore. Nor how to clear the damn things out! Adding toolkits should make the system as clear to understand as it was, not more complex. If it gets any worse it might as well be Windows 10!
init was easy to understand, easy to use. syslog was easy read easy to understand and easy to clear. All this bull about "it's a faster startup" is just ... well bull. I'm using a computer 20 times faster than I was a decade ago. You think 20 seconds off a minute startup is an achievement? It's seconds on a couple of days uptime; big f*cking deal.
Redhat, Fedora, turn away from the light and return to your roots!
I guess this one is still relevant?
"First they came for the slanderers and i said nothing."
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.
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.
> In short: I think chroot is plenty good for security
Check man chroot. The authors of chroot say it's useless for security. ,and more than security professionals like myself do. Let's find out.
Perhaps you think you know more than they do
> you get a shell in one of my chroot's used for security, then..... /dev, /proc, or other special filesystems
ur uid and gid are not going to be 0. Good luck telling the kernel to try and get you out.
There aren't going to be any
Gonna be kind of tthough to have a ahell without a tty, aka /dev/*tty* /dev. Can't launch a process, including /bin/ls, without /proc, so you're going to need proc. Have a look in /proc/1. You'll see a very interesting symlink there.
So yeah, you need
> mounted noexec
Noexec is basically a suggestion, not an enforement mechanism . Just run ld /path/to/executable. ld is the loader/lilinker for elf binaries. Without ld ,you can't run bash, or ls. With ld, noexec is ignored.
My company does IT security for banks. Meaning we show the banks how they can be hacked. When I say chroot is not a security control, I'm not guessing.
This has been going on for years, and has years more to go. This is a long term strategy.
But why?
Why has Red Hat been replacing standard Linux components with Red Hat components, when the Red Hat stuff is worse?
Why isn't systemd optional? It is just an init replacement, right? Why does Red Hat care which init you use?
Why is systemd being tied to so many other components?
Why binary logging? Who asked for that?
Why throw away POSIX, and the entire UNIX philosophy? Clearly you do not have to do that just to replace init.
Why does Red Hat instantly berate anybody who does not like systemd? Why the barrage of ad hominem attacks systemd critics?
I think there is only one logical answer to all of those questions, and it's glaringly obvious.