systemd-sysext, systemd-sysext.service, systemd-confext, systemd-confext.service - Activates System Extension Images

systemd-sysext [OPTIONS...] COMMAND

systemd-sysext.service

systemd-confext [OPTIONS...] COMMAND

systemd-confext.service

systemd-sysext activates/deactivates system extension images. System extension images may – dynamically at runtime — extend the /usr/ and /opt/ directory hierarchies with additional files. This is particularly useful on immutable system images where a /usr/ and/or /opt/ hierarchy residing on a read-only file system shall be extended temporarily at runtime without making any persistent modifications.

System extension images should contain files and directories similar in fashion to regular operating system tree. When one or more system extension images are activated, their /usr/ and /opt/ hierarchies are combined via "overlayfs" with the same hierarchies of the host OS, and the host /usr/ and /opt/ overmounted with it ("merging"). When they are deactivated, the mount point is disassembled — again revealing the unmodified original host version of the hierarchy ("unmerging"). Merging thus makes the extensions resources suddenly appear below the /usr/ and /opt/ hierarchies as if they were included in the base OS image itself. Unmerging makes them disappear again, leaving in place only the files that were shipped with the base OS image itself.

Files and directories contained in the extension images outside of the /usr/ and /opt/ hierarchies are not merged, and hence have no effect when included in a system extension image. In particular, files in the /etc/ and /var/ included in a system extension image will not appear in the respective hierarchies after activation.

System extension images are strictly read-only, and the host /usr/ and /opt/ hierarchies become read-only too while they are activated.

System extensions are supposed to be purely additive, i.e. they are supposed to include only files that do not exist in the underlying basic OS image. However, the underlying mechanism (overlayfs) also allows overlaying or removing files, but it is recommended not to make use of this.

System extension images may be provided in the following formats:

1.

Plain directories or btrfs subvolumes containing the OS tree

2.

Disk images with a GPT disk label, following the Discoverable Partitions Specification[1]

3.

Disk images lacking a partition table, with a naked Linux file system (e.g. erofs, squashfs or ext4)

These image formats are the same ones that systemd-nspawn(1) supports via its --directory=/--image= switches and those that the service manager supports via RootDirectory=/RootImage=. Similar to them they may optionally carry Verity authentication information.

System extensions are searched for in the directories /etc/extensions/, /run/extensions/ and /var/lib/extensions/. The first two listed directories are not suitable for carrying large binary images, however are still useful for carrying symlinks to them. The primary place for installing system extensions is /var/lib/extensions/. Any directories found in these search directories are considered directory based extension images; any files with the .raw suffix are considered disk image based extension images. When invoked in the initrd, the additional directory /.extra/sysext/ is included in the directories that are searched for extension images. Note however, that by default a tighter image policy applies to images found there, though, see below. This directory is populated by systemd-stub(7) with extension images found in the systems EFI System Partition.

During boot OS extension images are activated automatically, if the systemd-sysext.service is enabled. Note that this service runs only after the underlying file systems where system extensions may be located have been mounted. This means they are not suitable for shipping resources that are processed by subsystems running in earliest boot. Specifically, OS extension images are not suitable for shipping system services or systemd-sysusers(8) definitions. See the Portable Services[2] page for a simple mechanism for shipping system services in disk images, in a similar fashion to OS extensions. Note the different isolation on these two mechanisms: while system extension directly extend the underlying OS image with additional files that appear in a way very similar to as if they were shipped in the OS image itself and thus imply no security isolation, portable services imply service level sandboxing in one way or another. The systemd-sysext.service service is guaranteed to finish start-up before basic.target is reached; i.e. at the time regular services initialize (those which do not use DefaultDependencies=no), the files and directories system extensions provide are available in /usr/ and /opt/ and may be accessed.

Note that there is no concept of enabling/disabling installed system extension images: all installed extension images are automatically activated at boot. However, you can place an empty directory named like the extension (no .raw) in /etc/extensions/ to "mask" an extension with the same name in a system folder with lower precedence.

A simple mechanism for version compatibility is enforced: a system extension image must carry a /usr/lib/extension-release.d/extension-release.NAME file, which must match its image name, that is compared with the host os-release file: the contained ID= fields have to match unless "_any" is set for the extension. If the extension ID= is not "_any", the SYSEXT_LEVEL= field (if defined) has to match. If the latter is not defined, the VERSION_ID= field has to match instead. If the extension defines the ARCHITECTURE= field and the value is not "_any" it has to match the kernels architecture reported by uname(2) but the used architecture identifiers are the same as for ConditionArchitecture= described in systemd.unit(5). EXTENSION_RELOAD_MANAGER= can be set to 1 if the extension requires a service manager reload after application of the extension. Note that the for the reasons mentioned earlier: Portable Services[2] remain the recommended way to ship system services. System extensions should not ship a /usr/lib/os-release file (as that would be merged into the host /usr/ tree, overriding the host OS version data, which is not desirable). The extension-release file follows the same format and semantics, and carries the same content, as the os-release file of the OS, but it describes the resources carried in the extension image.

The systemd-confext concept follows the same principle as the systemd-sysext(1) functionality but instead of working on /usr and /opt, confext will extend only /etc. Files and directories contained in the confext images outside of the /etc/ hierarchy are not merged, and hence have no effect when included in the image. Formats for these images are of the same as sysext images. The merged hierarchy will be mounted with "nosuid" and (if not disabled via --noexec=false) "noexec".

Confexts are looked for in the directories /run/confexts/, /var/lib/confexts/, /usr/lib/confexts/ and /usr/local/lib/confexts/. The first listed directory is not suitable for carrying large binary images, however is still useful for carrying symlinks to them. The primary place for installing configuration extensions is /var/lib/confexts/. Any directories found in these search directories are considered directory based confext images; any files with the .raw suffix are considered disk image based confext images.

Again, just like sysext images, the confext images will contain a /etc/extension-release.d/extension-release.NAME file, which must match the image name (with the usual escape hatch of the user.extension-release.strict xattr(7)), and again with content being one or more of ID=, VERSION_ID=, and CONFEXT_LEVEL. Confext images will then be checked and matched against the base OS layer.

systemd(1), systemd-nspawn(1), systemd-stub(7)