it's not entirely clear to me if the manual NUL termination is
necessary, but let's better be safe than sorry, since this is apparently
up to the LSMs, and I am not sure we can trust them all.
A lot of other code (such as dbus-broker) patches in the NUL byte, hence
let's be rather safe-then-sorry, it's trivial after all.
Note sure why it didn't occur earlier to me, but now that we have this
nice helper to get the effective value of the set_login_environment
field instead of just falling back to "false".
Follow-up for: #30552
This geneally makes sense as setting up a PAM session pretty much
defines what a login session is.
In context of #30547 this has the benefit that we can take benefit of
the SetLoginEnvironment= effect without having to set it explicitly,
thus retaining some compat of the uid0 client towards older systemd
service managers.
ExecStart= and friends for .service and .socket can be specified
multiple times.
This also checks all commands for .mount and .swap, not only for the
current control command.
systemd-boot might be installed in /EFI/BOOT under more names than
just /EFI/BOOT/BOOTX64.efi. The prime example is shim which loads
its second stage binary from /EFI/BOOT/grubx64.efi. To accomodate
use cases where systemd-boot is installed as /EFI/BOOT/grubx64.efi,
let's always check the entire /EFI/BOOT directory for binaries that
identify as systemd-boot and list/update/remove those as well.
Let's keep this somewhat generic though and not install ourselves as
grubx64.efi since that would mean having to check for shim which is
a can of worms we probably don't want to open.
If the target mount point is an automount, checking it for writeability
without triggering it first is iffy and yields different results based
on kernel version:
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot'
Running as unit: run-u36.service; invocation ID: f948ff4f3c8e4bcfba364ead94bd0ad9
+ uname -r
4.18.0-529.el8.x86_64
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=43,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=356096)
+ test '!' -w /boot
Finished with result: exit-code
Main processes terminated with: code=exited/status=1
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot'
Running as unit: run-u274.service; invocation ID: ccc53ed63c3249348cf714f97a3a7026
+ uname -r
6.6.7-arch1-1
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
+ test '!' -w /boot
Finished with result: success
Main processes terminated with: code=exited/status=0
One solution would be to use /boot/ instead of just /boot, which triggers
the automount during the check, but in that case the mount would happen
_after_ we apply the ProtectSystem= stuff, so the mount point would
be unexpectedly writable:
~# systemd-run --wait --pipe -p ProtectSystem=yes bash -xec 'uname -r; mount -l | grep boot; test ! -w /boot/ || mount -l | grep boot'
Running as unit: run-u282.service; invocation ID: 2154f6b4cbd34ddeb3e246cb7c991918
+ uname -r
6.6.7-arch1-1
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
+ test '!' -w /boot/
+ mount -l
+ grep boot
systemd-1 on /boot type autofs (rw,relatime,fd=95,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=730583)
/dev/vda2 on /boot type vfat (rw,nosuid,nodev,noexec,relatime,nosymfollow,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
Let's just trigger the (possible) automounts explicitly before we do any
checks to avoid all this stuff.
Also, when at it, check that ProtectSystem=yes|full correctly protects
the ESP mount as well.
Follow-up for 97bbb9cfbd.
Otherwise we might occasionally hit the start rate limit, as we restart
the service a bunch of times:
[ 3702.280886] testsuite-75.sh[1135]: + tee /tmp/tmp.wUL8bkJwrt
[ 3702.283684] testsuite-75.sh[1135]: {}
[ 3702.284254] testsuite-75.sh[46]: + restart_resolved
[ 3702.284302] testsuite-75.sh[46]: + systemctl stop systemd-resolved.service
[ 3702.310678] testsuite-75.sh[1140]: + systemctl is-failed systemd-resolved.service
[ 3702.316766] testsuite-75.sh[1141]: inactive
[ 3702.316998] testsuite-75.sh[46]: + systemctl start systemd-resolved.service
[ 3702.322315] systemd[1]: systemd-resolved.service: Start request repeated too quickly.
[ 3702.322343] systemd[1]: systemd-resolved.service: Failed with result 'start-limit-hit'.
[ 3702.322609] systemd[1]: Failed to start systemd-resolved.service - Network Name Resolution.
[ 3702.323619] systemctl[1142]: Job for systemd-resolved.service failed.
[ 3702.323839] systemctl[1142]: See "systemctl status systemd-resolved.service" and "journalctl -xeu systemd-resolved.service" for details.
[ 3702.325035] systemd[1]: testsuite-75.service: Failed with result 'exit-code'.
[ 3702.325391] systemd[1]: Failed to start testsuite-75.service - Tests for systemd-resolved.
Follow-up for b1384db11b and 6ef512c0bb.
Yu Watanabe
Lennart Poettering
Michal Sekletar
Mike Yuan
Daan De Meyer
Franck Bui
Frantisek Sumsal
Luca Boccassi
Matteo Croce