reasoning: Dracut requires collecting files from the system directories to make an initramfs image. The files included in the base Snaps are not enough for this purpose. Canonical Kernel team requires this Snap to build the Ubuntu Core Snaps.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
The stated reasoning (collecting files from system directories) is a read access problem and strict confinement already solves it: system-backup exposes the whole host read-only under /var/lib/snapd/hostfs and dracut’s --sysroot supports building from an alternate root. File collection alone does not justify classic I feel.
What does justify it is execution. dracut-install resolves binary dependencies by invoking ldd, so dependency resolution requires executing content from the target tree. Under strict confinement exec is limited to the snap’s own runtime, that is the real blocker for strict and the gap worth capturing.
The packaging itself looks right for classic: dracut and 3cpio built from source, libkmod linked in-process, patchelf enabled so the core26-built binaries stay reliable in the host mount namespace.
Please state whether this is purely a build tool writing images into a work directory or whether end users are expected to regenerate their host initramfs with it (writing /boot, integrating with kernel hooks), since those carry different risk profiles.
One forward-looking note: exec-based resolution is only semantically valid when the target matches the running system. For cross-release sysroot builds it is the wrong mechanism anyway, and static ELF resolution (reading DT_NEEDED and walking the sysroot linker paths, lddtree-style) would be both more correct for that use case and compatible with strict confinement plus system-backup. If that lands in dracut-ng this snap should be able to move to strict, so this grant should be treated as revisitable.
+1 on classic based on the exec requirement in dracut’s current dependency resolution, with the reasoning above captured in place of the file collection argument.
It meant to be a build tool for generating Ubuntu Core initramfs files. The Snap description will be updated to say that the users should not use this Snap to generate their host system’s initrd images.
Thanks for confirming the scope, a description note is documentation rather than enforcement, but given the tool requires root and the stated audience is Core image builders I think that is acceptable. Having the wrapper refuse when the output path resolves under /boot would be a nice belt and braces addition if easy.
Classic has been granted to this snap, Publisher vetting has been done. this is now live.