Let's make our networkd sockets recognizable purely by name. It hink
already for debugging it's a good idea to always set socket names, in
particular for services that have multiple sockets they listen on.
This adds a name to the rtnl socket, which so far missed one. Note that
the C code won't look for it, for compat with older versions, but at
least things are a bit more debuggable.
Let's synthesize DNS RRs for leases handed out by our DHCP server. This
way local VMs can have resolvable hostnames locally.
This does not implement reverse look ups for now. We can add this
later in similar fashion.
We do this in a separate service (rather than inside of
systemd-tpm2-setup), since we want failures of this measurement to
result in an instant reboot, like for most our measurements.
Failures to initialize nvpcrs, or allocate an SRK are somewhat OK (and
more likely), as long as this separator communicates clearly where they
have to have taken place, if they worked.
This has irked me for a while. For me network configuration is the stuff
we store on disk in configuration file. And networkd then *applies* the
configuration. But the units so far claimed that networkd was the
"configuration" itself. Which I guess might make sense to some, but to
me sounds a bit unprecise. Let's clean this up, and call what networkd
is doing "Network Management".
Most of those were dropped in 7d247d3cb8. I left
behind the few cases where the 'output' name was different from the target name.
But we actually don't need those either, so get rid of those. (And one case
where I missed the name argument.)
No functional change, except that e.g. 'ninja -C build update-man-rules-impl'
doesn't work, but I hope nobody was using that.
The keymap only really matters if there's local access to a system, i.e.
if there's actually a physical kbd directly connected to it, to apply it
to. If during firstboot we are not talked to via a VT (but via SSH,
container, or hypervisor console or so instead), then it's very unlikely
we ever are. Hence, don't ask for a keymap, and let#s shortcut the
questions asked at boot.
For "wizard" style interactive tools it's very annoying if they are
interrupted by kernel log output or PID1's status output. let's add some
infra to disable this temporarily. I decided to implement this as an IPC
service so that we can make this robust: if the client request the
muting dies we can automatically unmute again.
This is hence a tiny varlink service, but it can also be started
directly from the cmdline.
Since mountfsd was added in 702a52f4b5 the
caps bounding set line was commented. That's an accident. Fix that. (We
need to add a bunch of caps to the list).
This adds TTYReset=yes to all units which run directly on the TTY. We
already had this in place for the gettys, but this adds it for the rest
that basically has StandardInput=tty + StandardOutput=tty set.
Originally, for these tools it wasn't necessary to reset the TTY,
because we after all already reset /dev/console very very early on once,
during PID1's early initialization, and hence there's no real reason to
do it again for these early boot services. But that's actually not
right, because since #36666 the TTY we reset from PID 1 is typically
/dev/console but the TTY those services are invoked on is typically the
resolved version of that, i.e. wherever that points. Now you might
think: if one is just an alias to the other, why does it matter to reset
this again? Well, because it's only a half-assed alias, and as it turns
out WIOCSWINSZ is not propagated from one to the other, i.e the terminal
dimesions we initialize for /dev/console don't propagate to whatever
that points to.
One option to address that would be to immediately propagate this down
ourselves (or to fix the kernel for it), but it felt safer to simply do
the reset again before the use, after all these one one-off services,
and there's no point in optimizing much here. Moreover, its probably
safer to give the guarantee that when the firstboot stuff (which after
all queries for pws to set) runs it definitely certainly guaranteed has
a properly reset terminal.
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able to have
it in /nix/store too like the other util-linux tools).
Given that `unmerged-usr` support was dropped in 255 I think this is a
safe change?
systemd-coredump sandbox already has ProtectSystem=strict hence all non
API filesystems are made read-only, thus RestrictSUIDSGID= doesn't buy
us much.
On top of that systemd-coredump's EnterNamespace= feature requires
openat2() to work correctly and that is implicitly blocked by
RestrictSUIDSGID=.
Follow-up for 8f8148cb08
This combines nicely with the X_SYSTEMD_UNIT_INACTIVE= notification
we send out, to ensure when all sshd units go down the actual
status is always reflected on the target.
We already check existences of quotaon in quotaon@.service and
quotacheck in systemd-quotacheck@.service.
Let's also check if kmod command exists.
Closes#38179.
Systemd-stub supports loading addons, credentials, system and
configuration
extensions from ESP and while addons and credentials can be both global
and
per-UKI, sysext/confext are only per-UKI.
Add support for global sysext/confext to systemd-stub/systemd-sysext.
Fixes#37993
vmspawn systems might take quite a while to boot in particular if they
go through uefi and wait for a network lease. Hence let's increase the
start timeout to 2min (from 45s). We'll do that for both nspawn and
vmspawn, even though the UEFI thing certainly doesn't apply there (but
the DHCP thing still does).
Load global sysext/confext from /.extra/global_{sysext,confext} which
systemd-stub puts there from ESP/loader/credentials/*.{sysext,confext}.raw.
Global extensions are handled the exact same way as per-UKI ones.
To implement --bind-user in systemd-vmspawn, we need a transient
version of these credentials. These are useful when the home directory
of the user is mounted into the container/vm and every trace of the user
will be (mostly) gone again when the container/vm is shut down.
closes#37602, see there for extra motivation and considered
alternatives.
On typical systems, only few services need to create SUID/SGID files.
This often is limited to the user explicitly setting suid/sgid, the
`systemd-tmpfiles*` services, and the package manager. Allowing a
default to globally restrict creation of suid/sgid files makes it easier
to apply this restriction precisely.
## testing done
- built on aarch64-linux and x86_64-linux
- ran a VM test on x86_64-linux, checking for:
- VM system boots successfully
- defaults apply (both `yes`, `no`, and undefined)
- systemd tmpfiles can set suid/sgid on journal log path
- Other services explicitly defining `RestrictSUIDSGID=no` can create
suid files
