This adds a new --background= switch that allows specifiying a
background color for the terminal while the tool runs.
It also teaches the tool when invoked as uid0 to tint the terminal in a
reddish hue when operating as root, and in a yellowish hue when
operating as any other user.
This should highlight nicely when the user is operating with elevated
privileges, or changed privileges.
As the bytes flow through our terminal forwarder we can color the
background of the terminal with a color of our choices, if that's
desired.
This will later allow us to color the background of the uid0 tool when
running as root with a slightly alarming red color.
This does two things:
1. When an ANSI sequence is seen that resets the background color, it is
extended to immediately set the color to our choice.
2. When a newline is seen it is immeidately extended to set the
background color again and clear the current line till the end.
Net effect: all lines written while we forward the ttys will be shown
with the background color of choice.
This turns "systemd-run" into a multi-call binary. When invoked under
the name "uid0", then it behaves a bit more like traditional "sudo".
This mostly means defaults appropriuate for that, for example a PAM
stack, interactivity and more.
Fixes: #29199
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.
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.
