Slashdot Mirror

← Back to Stories (view on slashdot.org)

Systemd Absorbs "su" Command Functionality

Posted by timothy on from the big-and-professional-like-gnu dept.

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.

10 of 747 comments (clear)

  1. Re:Bullshit by Anonymous Coward · · Score: 5, Informative

    Just like he considers exit statuses, stderr, and syslog "broken concepts." That is why systemd supports them so poorly. He just doesn't understand why those things are critical. An su system that doesn't properly log to syslog is a serious security problem.

  2. Only incidentally similar to su by butlerm · · Score: 5, Informative

    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.

  3. Is ANYONE editing this mess? by wonkey_monkey · · Score: 4, Informative

    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.
  4. Re:superuser by Anonymous Coward · · Score: 2, Informative

    Emacs is extensively documented.

  5. Re:quality engineering by Anonymous Coward · · Score: 2, Informative

    Getting this to work properly needs co-operation from the process that is orchestrating the different namespaces - the init system.

    It's only in the systemd architecture that the init system is the component that manages all flavours of namespace. Therefore your argument is circular.

  6. Re:BSD is looking better all the time by ezakimak · · Score: 4, Informative

    OpenRC++

    openrc init scripts are fairly straight forward.
    Coupled with gentoo's baselayout, and the config file layout is fairly normalized also.

  7. Re:What path have we chosen? by LVSlushdat · · Score: 3, Informative

    I currently run Ubuntu 14.04, and see where part of systemd has already begun its encroachment on what *had* been a great Linux distro. My only actual full-on experience so far with systemd is trying to get Virtualbox guest additions installed on a CentOS7 vm... I've installed those additions countless times since I started using VBox, and I think I could almost do the install in my sleep.. Not so with CentOS7.. systemd bitches loudly with strange "errors" and when it tells me to use journalctl to see what the error was, there *is* no error.. But still the additions don't install... I'm soooooo NOT looking forward to the next LTS out of Ubuntu, which I'm told will be infested with this systemd crap... Guess its time to dust off the old Slackware DVD and get acquainted with Pat again... GO FUCK YOURSELF, POETTERING.....

    --
    THANK YOU, Edward Snowden!! Americans owe you a debt of gratitude (whether they know it or not..)
  8. Re:What path have we chosen? by rl117 · · Score: 3, Informative

    The main thing I noticed with Ubuntu 15.04 at work is that rather than startup becoming faster and more deterministic as claimed, it's actually slower and randomly fails due to what looks like some race condition, requiring me to reset the machine. So the general experience is "meh", plus annoyance that it's actually degraded the reliability of booting.

    I also suffered from the "we won't allow you to boot if your fstab contains an unmountable filesystem". So I reformatted an ext4 filesystem as NTFS to accomplish some work task on Windows; this really shouldn't be a reason to refuse to start up. I know the justification for doing this, and I think it's as bogus as the first time I saw it. I want my systems to boot, not hang up on a technicality because the configuration or system wasn't "perfect". i.e. a bit of realism and pragmatism rather than absolutionist perfectionism--like we used to have when people like me wrote the init scripts.

  9. Re:chroot is not for security. like change directo by mysidia · · Score: 2, Informative

    You can ALWAYS "break out" of chroot.

    If you get a shell in one of my chroot's used for security, then.....

    • Your 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 /dev, /proc, or other special filesystems inside your chroot.
    • There aren't going to be any compilers or setuid binaries inside your chroot
    • If this is a FTP area, there won't be any binaries at all
    • Only the minimum files actually necessary for the program that uses that chroot are going to be found inside that chroot.
    • You won't have a chmod() command anywhere available inside that chroot.
    • All unnecessary POSIX capabilities will have been masked out from the process.
    • There won't be any writable locations in your chroot, the whole chroot will be mounted on a read-only file system, except if there is a place where writes are required by the legitimate software, And those mount points will have been marked as noexec.
    • The kernel will be running PaX or GRSecurity, such that most user data areas are non-executable, and memory pages expected to be executable of programs will get marked as read-only as they are launched, so only available binaries can be used to communicate with the kernel through syscalls.

    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.

  10. read the man page by raymorris · · Score: 5, Informative

    > In short: I think chroot is plenty good for security

    Check man chroot. The authors of chroot say it's useless for security.
    Perhaps you think you know more than they do ,and more than security professionals like myself do. Let's find out.

    > you get a shell in one of my chroot's used for security, then.....
    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 /dev, /proc, or other special filesystems

    Gonna be kind of tthough to have a ahell without a tty, aka /dev/*tty*
    So yeah, you need /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.

    > 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.