Re: RFC systemd-sysext/confext image context mounts

[Chris PeBenito <chpebeni@linux.microsoft.com>]

On 1/6/2026 12:01 PM, Dominick Grift wrote:
> 
> Chris PeBenito <chpebeni@linux.microsoft.com> writes:
> 
>> Systemd provides tools for composing directories like /usr and /opt
>> (system extensions, sysext) or /etc (configuration extensions,
>> confext).   These tools create an overlayfs at the target location,
>> with the root filesystem and extensions.  While they support raw
>> directories, files, and mutable filesystems, my current concern is
>> with extending immutable distributions at runtime using additional
>> immutable images.
>>
>> The challenge lies in ensuring proper labeling before deploying an
>> image, which is problematic for third-party images lacking labels or
>> using incompatible ones.  I haven't made any patches yet, as I want to
>> consult this group and the systemd developers first.  My proposal is:
>> for internally labeled filesystems (ext4, etc.), have the tools
>> validate the image's root directory label.  If validation fails, apply
> 
> Sounds fragile as these filesystems by definition have more then just a
> root directory.
> 
>> a context= mount using the label from the contexts/systemd_contexts
>> file in the policy.  I'd probably also add options in sysext.conf(.d)
>> and confext.conf(.d) to override this behavior, such as for specifying
>> an alternate label for the context mount.
>>
>> What are your thoughts?
> 
> I am not opposed per se but feels inconsistent. Consider for
> example verity authentication which will also most likely be used in
> these types of scenarios: why would one be able to deal with verity but
> not with selinux labels?

A third party would provide the hashtree and root hash along with the 
image.  If you're referring to a signature, that would be provided too. 
Are you expecting them to also put out an image every time someone comes 
up with a new policy variation?


> Also wondering where systemd is going to go with extensions will we get
> per-user instances that work together with systemd-mountfsd like we
> currently have with systemd-nspawn? If so how will that affect this design.
Can you elaborate?  I'm not familiar with these aspects.