Commit 88fce09026 modified the
mount_bind() function, causing it to perform arithmetic on the uid_shift
parameter. However, it performs this arithmetic even when uid_shift was
UID_INVALID, which was not intended. This typically occurred when
mount_custom() was called for a simple bind mount without user
namespaces (and thus no rootidmap mount option).
This arithmetic (e.g., uid_shift + m->destination_uid) then wraps
around, resulting in the invalid ID 4294967295 ((uid_t)-1).
This bug manifests for users running systemd-nspawn with
--link-journal=host and --volatile=yes (but without --private-users),
causing systemd-tmpfiles to fail.
Make mount_bind() robust by checking if uid_shift is valid before using
it in arithmetic. If it is UID_INVALID, it defaults to a shift of 0 for
the ownership calculation, restoring correct behavior for plain bind
mounts while preserving the intended logic for ID-mapped mounts.
Fixes: #39714
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 expose local VMs/containers under ._dhcp by default. Let's also
expose WIFI AP clients under .home.arpa (i.e. the RFC8375 domain for
home networks).
This function doesn't "connect" to Varlink (i.e. it isn't a client) but
it binds a Varlink socket (i.e. it is server), hence let's remove the
verb "connect" from its name. let's copy how machined/resolved name the
counterpart for this function: manager_varlink_init()
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.
Match the behaviour of the other test classes that use sd-run and
always create the mock tmpfs runtime dirs.
This will be needed as the new resolve.hook directory won't exist
on boot but will be needed by the test case.
This basically implements nss-myhostname, but natively in
systemd-resolved, so that the logic becomes available also for clients
using the local DNS stub for resolution or the D-Bus or Varlink APIs.
This introduces /run/systemd/resolve.hook/ as a new directory that local
(privileged) programs can bind a Varlink socket into. If they do they'll
get a method call for each attempted resolved lookup, which they can
then either process themselves (and generate new records for, or return
errors to block stuff) or let pass so that the regular resolution is
done.
Usecase for this is primarily two things:
1. in machined we can add local resolution of machine names to their IP
addresses, similar in fashion to nss-mymachines, but working also if
the non-NSS interfaces to name resolution are used, i.e. the local
DNS responder. In fact, I think we should eventually remove
nss-mymachines from our tree, as soon as this code in resolved is
setlled.
2. in networkd we can add local resolution of names specified in DHCP
leases we hand out.
But beyond that there should be many other uses, for example people
could write "dns firewalls" with this if they like where they
dynamically block certain names from resolution.
Fixes: #8518
Reverts systemd/systemd#38680
After taking a closer look I'm not convinced by the approach, see below.
First of all, all other SD_PATH_SEARCH_* are either somewhat generic,
i.e. encode the common prefix for configurations, binaries, etc., or are
subdirectories under systemd/ hence in our own "domain". The
tmpfiles/sysctl/binfmt we don't prefix with "systemd" precisely because
the concept is generic and there're actually other impls of them. A
specific SD_PATH_SEARCH_SYSCTL doesn't fit into our existing scheme.
Instead something along the lines of "SEARCH_SYSTEM_CONFIGURATION" shall
be introduced, and consumers will just suffix
sysctl.d/tmpfiles.d/binfmt.d for the final result.
And secondly, I don't grok why systemd-sysctl now unnecessarily calls
into sd-path to obtain the fixed search path. None of our other tools do
that.
-----------
An alternate approach, SD_PATH_SYSTEM_SEARCH_CONFIGURATION, which does
exactly above, will be introduced instead. It provides a universal
interface for querying any system config with our idiomatic
/etc/:/run/:/usr/local/lib/:/usr/lib/ hierarchy.
TPM2 support is not too useful if the firmware doesn't actually use it
for the boot chain, hence we require the full PC client profile support.
Let's make that clear in the docs.
Fixes: #38939
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.
