repart: support creating CopyFile= filesystems with fs-verity files

[allisonkarlitskaya]

Component

systemd-repart

Is your feature request related to a problem? Please describe

I'm creating operating system images containing fs-verity-enabled files. With tytso/e2fsprogs#203 I've verified that I can create an ext4 filesystem with fs-verity-enabled files created inside of it from the start, using mkfs.ext4 -O verity -d /path/to/files. Unfortunately that doesn't work with systemd-repart and CopyFiles= because the files are first copied to a temporary directory (like /var/tmp/.#repart7fca5bc0ddc4f765). It takes care to copy the file data, the xattrs, the permissions, and the access times, but doesn't check for fs-verity on the source and doesn't attempt to enable it on the destination.

Describe the solution you'd like

There are two options that would make me happy:

1. Allow skipping the copy to a temporary directory. In case there are no subdirectories that need masking out, it would actually be easier to just use the data directly from the source (unless I'm missing something).
2. If copying, check the origin file for fs-verity and enable it on the file in the temporary directory before calling the appropriate mkfs program.

• this could be a simple check by calling FS_IOC_GETFLAGS and enabling fs-verity with the default options;r or
• it could inspect the descriptor of the source file to try to do a "more accurate" job wrt. selection of hash algorithm, salt values, etc. I've never seen anything but the defaults used, though.

Bonus points: currently I have to say `SYSTEMD_REPART_MKFS_OPTIONS_EXT4='-O verity'. It would be cool if there was a config option for that, instead.

Describe alternatives you've considered

I've tried manually creating the filesystem image and using CopyBlocks= to copy it into the disk image, but this is pretty inconvenient. Aside from the obvious pain of the extra step, this argument (unlike CopyFiles) is not resolved relative to --root and demands to be given an absolute pathname. That makes it difficult to integrate into a build system that might be checked out in different places, without resorting to dynamically creating the repart.d/ files.

The systemd version you checked that didn't have the feature you are asking for

Fedora 41, systemd 256 (256.7-1.fc41) +PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE

[DaanDeMeyer]

Completely on board with this, might just take me some time before I find the time to implement it