singularity
singularity copied to clipboard
sylabs
Remove singularity runtime image driver plugin code
Type of issue
technical debt
Description of issue
SingularityCE has the concept of an image driver plugin, which implements filesystem related operations. At present it is only used in CE for the example ubuntu unpriv overlay plugin (https://github.com/sylabs/singularity/tree/main/examples/plugins/ubuntu-userns-overlay-plugin).
This plugin will be made irrelevant by #818 which will more generally permit unprivileged overlay.
Our longer term roadmap includes integrating runc as an alternative low-level runtime. This means that implementing fuse SIF / overlay etc. handling through the image driver mechanism is not a plausible strategy for CE.
Remove the image driver code after #818 is in place, to reduce the complexity of the singularity runtime image handling.
Our longer term roadmap includes integrating runc as an alternative low-level runtime. This means that implementing fuse SIF / overlay etc. handling through the image driver mechanism is not a plausible strategy for CE.
Why exactly are they mutually exclusive? Does runc manage its own mounting of the underlying container and starting overlayfs? Then how will CE implement unprivileged operation for the primary (non-alternate) low-level runtime?
Our longer term roadmap includes integrating runc as an alternative low-level runtime. This means that implementing fuse SIF / overlay etc. handling through the image driver mechanism is not a plausible strategy for CE.
Why exactly are they mutually exclusive? Does runc manage its own mounting of the underlying container and starting overlayfs? Then how will CE implement unprivileged operation for the primary (non-alternate) low-level run
runc doesn't mount the image. It runs a prepared image, in the OCI layout.
The image driver (plugin) hooks are quite deep inside the singularity runtime engine code. We will not be launching runc from within this code, and we don't want to duplicate the handling in the singularity runtime (for native/legacy), and outside (for runc). Therefore, we need to do things in a place outside of both runc and the singularity engine code.
SingularityCE will begin to diverge from Apptainer fairly significantly in some implementation detail from here, while focusing on user-level compatibility.
Expect some similarity to patterns of handling images / overlays etc. that are seen in other tools like sarus, and podman - but of course different as SIF is the primary format.
It sounds like the code for mounting things via setuid will also need to be shared with runc so then why not refactor the whole section including the image driver hooks into common code used by both the singularity runtime and the runc runtime?
I hope you are at least planning on doing unprivileged mounts from inside the initial user namespaces which have mounting privileges, and the image driver hooks have been perfectly placed to do that. Depending on fusermount as is the case currently with the CE --sif-fuse experimental option is very limiting, and just exchanging one type of setuid for another. If you want to be able to support non-setuid operation, unprivileged user namespaces will be required for that mode anyway so I think it makes sense to fully take advantage of them and do fuse mounts there.
@DrDaveD - We will be working to implement this stuff through CE 3.11 and into 4.0, and as mentioned already, we do expect to diverge implementation-wise from what Apptainer is doing. More image related functionality is quite likely to be factored out of the SingularityCE repo altogether, so that it can be employed elsewhere by consumers of SIF easily. The SingularityCE code still implements quite a lot of handling of images that would be useful to external tools... but the code is not well structured for import by others. See also #80
More generally around unprivileged, I think we have some different viewpoints between CE and Apptainer, and that's fine. It will be interesting to see how things fall out over time. We have more than a handful of users who cannot (due to site policy or other reasons) leverage unprivileged user namespaces, and we have heard concerns around FUSE SIF (esp. IOPs rather than BW) which haven't been completely assuaged by the benchmarking we have performed:
https://groups.google.com/g/singularity-ce/c/c4DjSWUAU5Q/m/3ei3m0zzCgAJ
From the changes to defaults coming in Apptainer 1.1, it's seems likely that you haven't been hearing the same concerns, and again, it's fine and likely beneficial that different approaches will be there for users.
With regard to 'fakeroot' we have some concerns over the overloading of this term. In upcoming apptainer releases --fakeroot moves from meaning one thing (a fake root user via full subuid/subgid mapping) to one of several different technical situations, depending on what subuid / namespace / helper exe functionality is available on the system. This is another area where perhaps our two projects have heard different but equally valid thoughts from users, so a different approach may be taken.
I'd like to draw a line under this thread for now. The overriding theme here, to my mind, should be that it is a good thing that the two projects will explore similar goals in different technical ways... while both being based on a common container format etc.