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.
There is no reason the creation of privileged sessions should depend on a particular init system. It's fairly obvious that is a bad idea from a software design perspective. The only architectural reason to build it like that is because so many distros already include systemd, so they don't have to worry about getting people to adopt this (incidentally, that's the same reason Microsoft tried to deeply embed the browser in their OS.....remember active desktop?)
If there are any systemd fans out there, I would love to hear them justify this from an architectural perspective.
"First they came for the slanderers and i said nothing."
Lennart Cartman certainly does love his systemd trapper keeper.
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.
How long until systemd absorbs emacs?
If su was part of your kernel, you were doing it wrong.
You should replace it with the fu command.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
That's what Poettering has been doing his whole life, getting into good open source projects, squatting and then shitting all over them. The infection, stink and filth then linger for decades. He's a cancer on open source.
... Lennart Poettering's long story short: "`su` is really a broken concept. ...
So every command that Poettering thinks may be broken is added to the already bloated systemd?
.
How long before there is nothing left to GNU/Linux besides the Linux kernel and systemd?
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.
So what you're saying is you like powershell?
Aliases are not realy a fix you can not reliably write shell script with them and stay portable.
No sir I dont like it.
I, for one, welcome this addition... every privilege escalation path you add is good for literally years of paid contract work.
"Delivering" the wrong thing is not an asset, it's a liability.
And that's why Poettering is a liability to the Linux community.
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'.
Did an editor even glance at this piece of crap before it was posted?
a su command functional
a) "an su." Write it like you'd say it.
b) what's a "command functional"?
c) you've got all the right words... just not necessarily in the right order
a lot concepts
I think you accidentally a word.
It will given you kind of a shell
Can it has cheezeburger too?
systemd is Roko's Basilisk.
As before by "fixing" more things that are not broken. It is really time to stop this abomination. Sure, there are some (few) things it does that actually have merit, but it doe them in the wrong way, and most of it is just plain bad for security, reliability and user choice. Why so much of the Linux infrastructure is handed willingly to this one bad actor is beyond me.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.
I can see that as being one of his goals but if you want to improve Linux why a new init system plus? I did not hear any system admins asking for this.
He would be considered a saint if he would do something useful like fix the desktop environments so the "Year of the Linux Desktop" finally gets here.
A man who wants nothing is invincible
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."
Please remember devuan (http://www.devuan.org), a Debian fork which aims to do away with systemd and all that bullcrap. It's picking up steam, and I believe things like these make it more and more worth it to help the new fork.
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
"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
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!
Lennart Poettering's long story short: "`su` is really a broken concept
Of course to Lennart Poettering "su" is broken !!
Long story short --- To that egotistical son of a bitch, anything that is not made by him MUST BE 'broken'
'nuff said!
Muchas Gracias, Señor Edward Snowden !
.
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.
I had trouble with init scripts. The systemd init subsystem was a better approach. The problem was, systemd also brought in a lot of stuff that wasn't directly part of the init subsystem that I didn't want, don't want, and don't see any probability of ever wanting.
Because Poettering doesn't understand "modular", I don't get just the good stuff - it's all or nothing. And because systemd isn't even modular as an overgrown bloated monstrosity, the only way to avoid it is to either run old distros or some other OS entirely.
OpenRC++
openrc init scripts are fairly straight forward.
Coupled with gentoo's baselayout, and the config file layout is fairly normalized also.
I had trouble with init scripts. The systemd init subsystem was a better approach. The problem was, systemd also brought in a lot of stuff that wasn't directly part of the init subsystem that I didn't want, don't want, and don't see any probability of ever wanting.
Yeah, that's basically the problem. Systemd is really three different things:
1) init system
2) cgroups manager (cgroups architecture is still crap, btw)
3) session manager
It probably does more stuff, but it's hard to keep track of it all
"First they came for the slanderers and i said nothing."
So, now we have to say "machinectl shell systemd-run do make me a sandwich" ?
Looks way more complicated.
https://xkcd.com/149/
PoetteringOS
In the long run, he's not going to be satisfied until he's created his own OS, kernel and all because he calls anything he didn't write a "broken concept," whatever that is, and does his best to shove his version down everybody's throat. And, since his version is far more complex, far more pervasive and much, much harder to use or maintain, the community suffers. I do wish he would get off the pot and start developing the One True (Pottering) kernel so that the rest of the world can go back to ignoring him.
Good, inexpensive web hosting
This systemd guy is just like Ellsworth Toohey. As long as the sheep follow he'll keep pushing things further and further into idiotland and have a good laugh in the process.
"Kill man’s sense of values. Kill his capacity to recognise greatness or to achieve it. Great men can’t be ruled. We don’t want any great men. Don’t deny conception of greatness. Destroy it from within. The great is the rare, the difficult, the exceptional. Set up standards of achievement open to all, to the least, to the most inept – and you stop the impetus to effort in men, great or small. You stop all incentive to improvement, to excellence, to perfection. Laugh at Roark and hold Peter Keating as a great architect. You’ve destroyed architecture. Build Lois Cook and you’ve destroyed literature. Hail Ike and you’ve destroyed the theatre. Glorify Lancelot Clankey and you’ve destroyed the press. Don’t set out to raze all shrines – you’ll frighten men, Enshrine mediocrity - and the shrines are razed."
-- Ellsworth Toohey
lucm, indeed.
You can ALWAYS "break out" of chroot.
If you get a shell in one of my chroot's used for security, then.....
In short: I think chroot is plenty good for security. There's no way in hell you are breaking out, without a straight up kernel arbitrary execution exploit.
> 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.
Yes and init scripts are just a bastion of race-free stateful design, and service monitoring. Except not at all those things.
Well put. The notion that *nix is a structure built by many people, with many bricks (and many eyes on each) is being violated. Its not about using larger bricks, its about using one brick? How will that brick be patched? How many eyes are on that brick? How does the community build and grow Systemd? Its time for a split,probably going back to volkerding's work, or BSD and rethinking init and networking and .. sure. sudo as well.
Who has the leverage to ask why more is being done by fewer and fewer?
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
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.