Ideally we would like to hide all other service's credentials for all
services. That would imply for us to enable mount namespacing for all
services, which is something we cannot do, both due to compatibility
with the status quo ante, and because a number of services legitimately
should be able to install mounts in the host hierarchy.
Hence we do the second best thing, we hide the credentials automatically
for all services that opt into mount namespacing otherwise. This is
quite different from other mount sandboxing options: usually you have to
explicitly opt into each. However, given that the credentials logic is a
brand new concept we invented right here and now, and particularly
security sensitive it's OK to reverse this, and by default hide
credentials whenever we can (i.e. whenever mount namespacing is
otherwise opt-ed in to).
Long story short: if you want to hide other service's credentials, the
most basic options is to just turn on PrivateMounts= and there you go,
they should all be gone.
When removing a directory tree as unprivileged user we might encounter
files owned by us but not deletable since the containing directory might
have the "r" bit missing in its access mode. Let's try to deal with
this: optionally if we get EACCES try to set the bit and see if it works
then.
It appears LOOP_CONFIGURE in 5.8 is even more broken than initially
thought: it doesn't properly propgate lo_sizelimit to the block device
layer. :-(
Let's hence check the block device size immediately after issuing
LOOP_CONFIGURE, and if it doesn't match what we just set let's fallback
to the old ioctls.
This means LOOP_CONFIGURE currently works correctly only for the most
simply case: no partition table logic and no size limit. Sad!
(Kernel people should really be told about the concepts of tests and
even CI, one day!)
When assembling a disk image locally, using --size=auto can be used to
generate the minimal image based on the provided definitions. THis is
useful to prepare images that are grown on first boot.
This matches how we handle things everywhere else, i.e. in .mount units,
and similar: when a mount point dir is missing, we create it, let's do
so too when dealing with disk images.
This makes things a lot simpler, more robust, and systematic.
Wiping means writing zero sectors to disk. Hence it's better to do this
before we discard, so that the zeroes we use to overwrite are properly
discarded. If we'd do it the other way round we'd discard the data and
then reallocte it just to write zeroes.
We initialize the partition contents before the partitions actually
exist, hence to reduce confusion let's talk about "future partitions" up
to the point where they are actually realized.
Let's issue the wiping ourselves, so that we know it's done before we
write partition data onto the disk, and before the disk label
is written. Before this commit the writing of the disk label would imply
the wiping step, potentially overriding again what we just wrote into
the disk data section.
(Normally this shouldn't matter, since the partition table metadata
that the wiping process deletes is at the start and end of the disk
while we write our data to the middle, but you never know what kind of
weird signatures might exist that depart from that.)
(And effectively this ends up using the same wiping code, since that's
implemented in libblkkid, and libfdisk just acts as frontend to that
anyway. We now simply call it directly.)
fat is a bit more limited in volume name length and UUID support. Let's
add some special support for it.
This is particularly useful to generate EFI system partitions.
The context_unload_partition_table() call is supposed to remove all
data from the loaded partitions about how we mapped it to existing
partitions on disk, but it should leave everything we parsed from the
definition files in place.
We mostly got this right, except for two cases:
1. new_uuid is parsed from the definition files and should stay
2. current_label is read from the existing partition table and should be
freed
"Linux" conflicts /efi/Linux when /efi is the install location.
/efi/Linux is already reserved for unified kernel images so we can't use
it for type #1 images. Instead, we use "Default".
Lennart Poettering