So far we created the target directory, and the source for bind mounts,
but not workdir/upperdir for overlays, so it has to be done separately
and strictly before the unit is started, which is annoying. Check the
options when creating directories, and if upper/work directories are
specified, create them.
cryptsetup reads a bunch of credentials now but we don't pass import
those in any service units yet. Let's pass through all cryptsetup
prefixed credentials to the systemd-cryptsetup@root instance.
Request with Range header like 'entries=<cursor>:' (with a colon at the end,
invalid syntax per the doc), is now rejected with error 400 Bad Request.
fix#4883
This adds a new ProtectSystem= setting that mirrors the option of the
same of services, but in a more restrictive way. If enabled will remount
/usr/ to read-only, very early at boot. Takes a special value "auto"
(which is the default) which is equivalent to true in the initrd, and
false otherwise.
Unlike the per-service option we don't support full/strict modes, but
the door is open to eventually support that too if it makes sense. It's
not entirely trivial though as we have very little mounted this early,
and hence the mechanism might not apply 1:1. Hence in this PR is a
conservative first step.
My primary goal with this is to lock down initrds a bit, since they
conceptually are mostly immutable, but they are unpacked into a mutable
tmpfs. let's tighten the screws a bit on that, and at least make /usr/
immutable.
This is particularly nice on USIs (i.e. Unified System Images, that pack
a whole OS into a UKI without transitioning out of it), such as
diskomator.
This is a fancy wrapper around "cat <<EOF", but:
- the user doesn't need to figure out the file name,
- parent directories are created automatically,
- daemon-reload is implied,
so it's a convenient way to create units or drop-ins.
Closes https://github.com/systemd/systemd/issues/21862.
I see myself frequently typing in "journalctl --file=…". That's a lot to
type. Let's add a short switch too. Unfortunately, "-f" and "-F" are
already taken, hence let's pick "-i".
The header and keyfile are necessary only for opening the device, not
for closing, so it is not necessary to deactivate the generated
cryptsetup unit when the header or keyfile backing store are removed.
This is especially useful in the case of softreboot, when the new
mount root is setup under /run/nextroot/ but we don't want to close
the cryptsetup devices for encrypted /var/ or so, and we simply
mount it directly on /run/nextroot/var/ before the soft-reboot.
