Check existing issues
Request
We have an ongoing effort in snapd to make the handling of snap mount namespaces more robust. This includes ways for simplifying the hierarchy of mounts that are required in order to produce the world view that the snap declared in its snap.yaml. A dedicated piece of snapd - snap-update-ns - is ultimately responsible for making this happen and it does it by various combinations of tmpfs/bind mounts/and mock paths that serve as mount points. Specifically, in the context of this request, in situations when a target of a content mount does not exist e.g. $SNAP/target, s-u-n will do the following (simplified):
- create a tmpfs on the side
- bind mount everything from under the original
$SNAP location
- mkdir
target
- bind mount the temporary directory back onto
$SNAP
This nicely illustrates the additional complexity which could be entirely avoided should $SNAP/target already exist inside the squashfs blob. Things only get more complicated form here where the snap adds layout on top, or the content provider snap is refreshed.
Since the ultimate goal is to make things simpler, easier to set up, debug and reason about we, on the snapd side, are considering making the presence of content interface target location presence mandatory for snaps using base core26 and later. I have a draft PR in snapd canonical/snapd#16828 which adds the code to enforce this.
Let's discuss whether snapcraft could make this transition simpler by ensuring that the directories are created at build time.
The problem it solves
Simplifies steps needed to create the mount setup requested by a snap and thus helps snapd with making snap mount namespaces more robust.
Check existing issues
Request
We have an ongoing effort in snapd to make the handling of snap mount namespaces more robust. This includes ways for simplifying the hierarchy of mounts that are required in order to produce the world view that the snap declared in its snap.yaml. A dedicated piece of snapd - snap-update-ns - is ultimately responsible for making this happen and it does it by various combinations of tmpfs/bind mounts/and mock paths that serve as mount points. Specifically, in the context of this request, in situations when a target of a content mount does not exist e.g.
$SNAP/target, s-u-n will do the following (simplified):$SNAPlocationtarget$SNAPThis nicely illustrates the additional complexity which could be entirely avoided should
$SNAP/targetalready exist inside the squashfs blob. Things only get more complicated form here where the snap addslayouton top, or the content provider snap is refreshed.Since the ultimate goal is to make things simpler, easier to set up, debug and reason about we, on the snapd side, are considering making the presence of
contentinterfacetargetlocation presence mandatory for snaps using base core26 and later. I have a draft PR in snapd canonical/snapd#16828 which adds the code to enforce this.Let's discuss whether snapcraft could make this transition simpler by ensuring that the directories are created at build time.
The problem it solves
Simplifies steps needed to create the mount setup requested by a snap and thus helps snapd with making snap mount namespaces more robust.