With this pull request systemd now support a
su command functional and can create privileged sessions, that are fully isolated from the original session.
Su is a classic UNIX command and used more than 30 years. Why
su is bad? Lennart Poettering says:
Well, there have been long discussions about this, but the problem is that what su is supposed to do is very unclear. On one hand it’s supposed to open a new session and change a number of execution context parameters (uid, gid, env, …), and on the other it’s supposed to inherit a lot concepts from the originating session (tty, cgroup, audit, …). Since this is so weakly defined it’s a really weird mix&match of old and new paramters. To keep this somewhat managable we decided to only switch the absolute minimum over, and that excludes XDG_RUNTIME_DIR, specifically because XDG_RUNTIME_DIR is actually bound to the session/audit runtime and those we do not transition. Instead we simply unset it.
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.
THis has come up many times, but nothing really changed, hence closing this now. I understand this is confusing and unexpected, but well, that’s UNIX…
New feature included in latest version of systemd and we cat test it now:
$ cat /etc/os-release NAME=Fedora VERSION="24 (Workstation Edition)" ID=fedora VERSION_ID=24 PRETTY_NAME="Fedora 24 (Workstation Edition)" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:fedoraproject:fedora:24" HOME_URL="https://fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=Rawhide REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=Rawhide PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy VARIANT="Workstation Edition" VARIANT_ID=workstation $systemctl --version systemd 225 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
Login as superuser without
$ machinectl shell Connected to the local host. Press ^] three times within 1s to exit session. sh-4.3# id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0 sh-4.3# whoami root sh-4.3#
It works! We can work as superuser. And isn’t end: we can also set shell and host:
$ machinectl shell root@.host /bin/bash Connected to the local host. Press ^] three times within 1s to exit session. [root@localhost /]# id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0
Login as non-root user and set variable of shell environment:
$ id uid=1000(paul) gid=1000(paul) groups=1000(paul) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 #1000 - UID of user `paul` #SYSTEMD_TEST - test variable of user environment $ machinectl shell --uid 1000 --setenv="SYSTEMD_TEST=777" Connected to the local host. Press ^] three times within 1s to exit session. sh-4.3$ id uid=1000(paul) gid=1000(paul) groups=1000(paul) context=unconfined_u:unconfined_r:unconfined_t:s0 sh-4.3$ whoami paul sh-4.3$ export | grep -i systemd export SYSTEMD_TEST="777" sh-4.3$
Great! Our variable is defined. More complicated trick (thanks to Igor Gnatenko):
$ sudo systemd-run -p CPUQuota=50% -p PAMName=login -t /bin/bash -l
We run new shell session and set CPU quota only 50% – very useful if you have high load services.￼