name_to_handle_at_try_unique_mntid_fid() in its current form is
ill-designed for various reasons:
* AT_HANDLE_FID requires file system support, while unique mount id
is a VFS concept hence is always available if supported. Hence
the fallback for AT_HANDLE_MNT_ID_UNIQUE should be independent
of fid.
* The request for AT_HANDLE_MNT_ID_UNIQUE can be identified via
specifying ret_unique_mnt_id, no need for opening up the control
to caller (and currently the function simply doesn't handle
mismatch between ret params and flags).
* The caller cannot realistically differentiate whether the returned
mount id is actually unique.
* The path_get_unique_mnt_id() fallback did not handle AT_SYMLINK_FOLLOW.
Let's instead move the statx() fallback into name_to_handle_at_loop()
directly, and revamp interaction of ret_mnt_id/ret_unique_mnt_id:
if both are set, it indicates that the caller can handle both, hence
set what we have and return 0/1 for whether we managed to acquire
the unique one.
The !ret_handle && ret_mnt_id logic is removed. Let's not rely on
undocumented bizaare behavior and it's unused anyways.
path_get_mnt_id_at() exists for a reason...
When the extensions for the final system are already set up from the
initrd we should avoid disrupting the boot process with the remount
(which currently isn't atomic) and the daemon reload for
systemd-confext and systemd-sysext. Similarly, when sysupdate ran and
updated extensions it's best to avoid the remount and daemon reload if
no changes are found.
To do this, encode the current extension state in more detail than
before where only the names of the extensions where encoded in the
overlay mount. This can also be used to provide more details about the
extension origin in "systemd-sysext status (--json=)". During the
refresh add a check whether the old state matches the new state and in
this case skip the refresh unless the user provides a flag to always
refresh. Besides the extension name and the resolved path the best
method for identification is the verity hash but that is not available
for plain image files or directories. Therefore, also include data to
check for file/directory replacements. The creation/modification times
are not always real on reproducible images or extracted archive content.
The file handle together with the unique mount ID is the next best
identifier we can use when we have no verity hash. Fall back to an inode
when we get no handle. With the creation/modification time and the path
this should be good enough. Using a unique mount ID is important (with
a fallback to the regular non-unique mount ID) instead of st_dev because
st_dev gets reused too easily, e.g., by a loop device mount and the
mount ID helps to catch this. For the mount ID to be valid it has to be
resolved before we enter the new mount namespace. Thus, it gets provided
by the image dissect logic and handed over to the sysext subprocess
which runs in a new mount namespace.
Luckily, we can rule out online modification of directories or image
files because this is anyway not well supported with overlay mounts, so
we don't do a file checksum nor do we recurse into a directory to look
for the most recently touched files. But, as said, with the
always-refresh flag one can force a reload.
Now that the necessary functions from log.h have been moved to macro.h,
we can stop including log.h in macro.h. This requires modifying source
files all over the tree to include log.h instead.
To resolve conflict with sys/mount.h and linux/mount.h or linux/fs.h.
The conflict between sys/mount.h and linux/mount.h is resolved in
glibc-2.37 (774058d72942249f71d74e7f2b639f77184160a6), but our baseline
is still glibc-2.31. Also, even with the version or newer, still
sys/mount.h conflicts with linux/fs.h, which is included by
linux/btrfs.h.
This introduces our own implementation of sys/mount.h, that can be
simultaneously included with linux/mount.h and linux/fs.h. This also
imports linux/fs.h, linux/mount.h, and several other dependent headers.
The introduced sys/mount.h header itself may not be enough simple, but
by using the header, we can drop most of workarounds in other source files.
Two error conditions are unreachable, as now both glibc and kernel
support statx(). In other many places, failure in statx() are handled as
critical, even if it is filtered by seccomp or so. Let's follow the same
way here.
struct statx in glibc header was introduced in glibc-2.28
(fd70af45528d59a00eb3190ef6706cb299488fcd), but at that time,
sys/stat.h conflicts with linux/stat.h. Since glibc-2.30
(5dad6ffbb2b76215cfcd38c3001778536ada8e8a), sys/stat.h includes
linux/stat.h if exists.
Since now our baseline of glibc is 2.31. Hence, we can drop workarounds
for struct statx by importing linux/stat.h from newer kernel (v6.14-rc4).
- Drop fstat() fallback path now that we assume fdinfo
is available
- Use at_flags_normalize_nofollow()
- Accept empty path the same way as NULL
- Accept fd being AT_FDCWD and filename being "."
Avoid showing the files on the ESP (i.e. a FAT formatted volume) as
executable by removing the execute permission from them.
IMO this makes the colored output of `ls` more sensible since the file
system will be mounted with `noexec` anyway.
Add a `fstype_can_fmask_dmask` function that checks if a file system
type can use the `fmask` and `dmask` mount options.
This replaces `fstype_can_umask` since it was only used in
`partition_pick_mount_options` which only cares about the file system
support for fmask & dmask now.
It somewhat reduces the coverage of the feature since there are more file
systems that support umask as opposed to those supporting dmask & dmask,
but it should not be much of an issue since fmask & dmask are supported
by vfat, exfat and ntfs3.
In the unlikely event that sandboxes block statx() but let
name_to_handle_at() through it's a good way to determine the root inode
of the namespace, since its parent inode will have the same FID and
mnt_id.
Newer kernels support a new flag for name_to_handle_at(): AT_HANDLE_FID.
This flag is supposed to return an identifier for an inode that we can
use for checking inode identity. It's supposed to be a replacement for
checking .st_ino which doesn't work anymore today because inode numbers
are no longer unique on file systems (not on overlayfs, and not on btrfs
for example). Hence, be a good citizen and add infrastructure to support
AT_HANDLE_FID. Unfortunately that doesn't work for old kernels, hence
add a fallback logic: if we can use the flag, use it. If we cannot use
name_to_handle_at() without it, which might give us a good ID too. But
of course tha tcan fail as well, which callers have to check.
And while we are at it, make it use ERRNO_IS_xyz() where appropriate.
And move it up a bit, so we can use in the whole of mountpoint-util.c
(which we want to later).
mount_option_supported() will call fsopen() which will probe the
kernel filesystem module. This means that we'll suddenly start
probing filesystem modules when running generators as those determine
which mount options to use. To prevent generators from loading kernel
filesystem modules as much as possible, let's always first check the
hardcoded list of filesystem which we know support a feature before
falling back to asking the kernel.
Previously, in path_is_root_at(), if statx() does not provide mount ID,
path_get_mnt_id_at() was called, but it also calls statx(). Let's avoid
the second trial.
Lennart Poettering
Pontus Lundkvist
Mike Yuan
Kai Lueke
Yu Watanabe
Daan De Meyer
nl6720
Luca Boccassi
Lennart Poettering
Zbigniew Jędrzejewski-Szmek