Live Modification Of Mount Namespaces
This page contains a draft specification for an upcoming feature
Snapd puts each application process belonging to a given snap to a namespace associated with that snap. For snaps that are using strict or devmode confinement, this namespace is unique to the snap. For snaps that are using classic confinement, this namespace is the main mount namespace of the rest of the system.
The first process belonging to a given snap will cause the namespace to be fully initialized and preserved. Initialization involves generic isolation operations that are common to all the snaps as well as a set of operations that are specific to the snap at hand, such as mount profiles mandated by interfaces.
Once the namespace is created it is kept until the snap is removed or until the machine is rebooted. This specifically means that the namespace outlives the process that created it.
When an interface is connected or disconnected the effective mount profile, understood as a list of mount operations that should have been performed in a given namespace, may become out of date. As a simple example consider the act of connecting a content interface. The snap on the plug side of the connection should see additional mount entries corresponding to the specification of the shared content.
As of snapd 2.20.1 there is no mechanism alters mount table at the time
interface connections are changed. Since snapd 2.21 the following things
happen whenever the mount backend is setup for a given snap.
- The desired mount profile for a given snap is computed.
- The computed profile is saved to the existing mount profile file (aka
fstab) - A new tool
snap-alter-nsis invoked. The tool is described below.
This new tool is implemented in C and interacts with the locking protocol used to initialize and join mount namespaces. The tool has one responsibility: to modify the mount namespace to match the desired profile.
The tool starts by associating with the desired mount namespace. If the namespace does not exist then the tool quits successfully as nothing more needs to be done.
In the desired namespace the tool loads the status of the namespace by
inspecting /proc/self/mountinfo and correlates this information with the
desired mount profile stored in /var/lib/snapd/mount/$SNAP_NAME.fstab as well
as the previously seen profile that is saved in
/run/snapd/ns/$SNAP_NAME.fstab. If either of the profiles don't exist the
tool quits.
The mount profile from the initial construction of the mount namespace saved in
/run/snapd/ns/$SNAP_NAME.fstab. Each line in that file corresponds to a
mount operation. It is possible to compute a reverse operation (unmount) for
each of the operations specified there.
The current and desired profiles are then compared. Each entry that doesn't exist in the current profile but exists in the desired results with a mount operation. Each entry that doesn't exist in the desired profile but exists in the current profile results in an unmount operation. All unmount operations are performed first, before the first mount operation.
As a future optimization we may support a subset of remount operations (e.g. to change the read only / read write mount flag) but this is not considered at this stage.
Once all mount operations are performed the desired mount profile is copied to the current mount profile.
The discard tool will now unlink the current profile after successfully unmounting the preserved namespace.
violethaze74 This is the snapd wiki, feel free!