We already checked the flags before, and updated the state accordingly,
hence let's only look at the state afterwards. This allows us to use the
same expressions for all cases where we want to reply automatically to
clients.
Let's make sure method call handlers failing will result in that very
method call failing but not the whole connection. We mostly got that
right, except for "oneway" calls where the method reply is supposed to
be eaten up, but wasn't. Fix that.
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.
These tests are not interested in most addresses specified in the .network file.
As 10-many-address.conf drop-in config for the .network file contains so
many addresses, hopefully this improves test performance.
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.
Yu Watanabe
Lennart Poettering
Michal Sekletar
Mike Yuan
Daan De Meyer
Franck Bui
Frantisek Sumsal
Vladimir Stoiakin