This does what we already do for the LUKS backend: instead of mounting
the source directory directly to the final home dir, we instead bind
mount it to /run/systemd/user-home-mount (where /run/ is unshared and
specific to our own mount namespace), then adjust its mount flags and
then bind mount it in a single atomic operation into the final
destination, fully set up.
This doesn't improve much on its own, but it makes things a tiny bit
more correct: this way MS_NODEV/MS_NOEXEC/MS_NOSUID will already be
applied when the bind mount appears in the host mount namespace, instead
of being adjusted after the fact.
Doing things this way also makes things work more like the LUKS backend,
reducing surprises. Most importantly it's preparation for doing
uidmapping for directory homes, added in a later commit.
For the other backends we synthesize a "binding" section in the json
record of the user that stores meta info how a user record is "bound" to
the local host. It declares storage info and such. Let's do the same for
the directory/subvolume backends.
Let's migrate home_create_directory_or_subvolume() to also use HomeSetup
for storing its runtime objects we'd like to destroy in case of failure.
In the beginning this is just the root_fd, but later on we can add more.
No change in behaviour, just shifting things around.
Previously, valid_until (or preferred_until for preferred lifetime) was
calculated from lifetime. So, when an upstream interface acquire a
dynamic prefix (e.g. through DHCPv6-PD) with long lifetime, then sd-radv
advertise the same lifetime. It may not be desired for some situations.
Let's make sure '@' is never written as entry ID into any EFI variable,
as we want the ability to add new ids like this later on, with them
resulting in a clear error on older implementations.
mkosi automatically builds for the host distro which seems a much
better default to encourage since dnf won't be installed on any host
system that's not Fedora anyway.
Detection of VirtualBox is accomplished in the existing code by *either* `innotek GmbH`
or `Oracle Corporation` existing in any of:
- /sys/class/dmi/id/product_name
- /sys/class/dmi/id/sys_vendor
- /sys/class/dmi/id/board_vendor
- /sys/class/dmi/id/bios_vendor
With Oracle's physical servers, both `/sys/class/dmi/id/sys_vendor` and
`/sys/class/dmi/id/board_vendor` contain `Oracle Corporation`, so those
servers are detected as `oracle` (VirtualBox).
VirtualBox has the following values in the latest versions:
- /sys/class/dmi/id/product_name: `VirtualBox`
- /sys/class/dmi/id/sys_vendor: `innotek GmbH`
- /sys/class/dmi/id/board_vendor: `Oracle Corporation`
- /sys/class/dmi/id/bios_vendor: `innotek GmbH`
Presumably the existing check for `innotek GmbH` is meant to detect
older versions of VirtualBox, while changing the second checked value
from `Oracle Corporation` to `VirtualBox` will reliably detect later and future
versions.
JSON doesn't have NaN/infinity/-infinity concepts in the spec.
Implementations vary what they do with it. JSON5 + Python simply
generate special words "NAN" and "Inifinity" from it. Others generate
"null" for it.
At this point we never actually want to output this, so let's be
conservative and generate RFC compliant JSON, i.e. convert to null.
One day should JSON5 actually become a thing we can revisit this, but in
that case we should implement things via a flag, and only optinally
process nan/infinity/-infinity.
This patch is extremely simple: whenever accepting a
nan/infinity/-infinity from outside it converts it to NULL. I.e. we
convert on input, not output.
The setting is completely meaningless, as WithoutRA= and UseDelegatedPrefix=
in [DHCPv6] section, and DHCPv6Client= in [IPv6AcceptRA] section control
the behavior.
Lennart Poettering
Daan De Meyer
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Greg Zuro
Bastien Nocera
Frantisek Sumsal