Shared Subtrees

The mechanisms I have discussed so far covered the standard mount cases that are available on any Unix system. However, Linux supports some more advanced possibilities that allow for gaining more power from namespaces. Since they were only introduced during the development of 2.6 (2.6.16, to be precise), their use is still somewhat limited, so I will briefly review their basic principle before I discuss the implementation. For specific details on potential applications and a precise description of the shared subtree semantics of the mount tool, see the manual page mount(8). Another detailed investigation of the features provided by shared subtrees can be found on http://lwn.net/Articles/159077/.

The extended mount options (which I collectively call shared subtrees) implement several new attributes for mounts:

□ Shared Mounts — A set of mounted filesystems between which mount events are propagated. If a new filesystem is mounted into one member of the set, the mount is replicated into all other members of the set.

□ Slave Mounts — Similar to shared mounts, except that the symmetry between all members of the set is removed. One mount in the set is especially distinguished as the master mount. All mount operations in the master mount propagate into the slave mounts, but mount operations in the slaves do not propagate back into the master.

□ Unbindable Mounts — Cannot be cloned through a bind operation.

□ Private Mounts — essentially a new name for the classical mount type known from Unix: They can be mounted on multiple places across the filesystem, but mounts propagate neither to nor from them.

usbstick virtual

I I

media virtual a b c media

usbstick virtual r usr

I I r media virtual usbstick a b c n r media

usbstick usr media virtual

usr media usbstick virtual r r i usr media virtual virtual i r i usr r media virtual usr media virtual

usbstick camera usbstick Figure 8-7: Illustration of some features provided by shared subtrees.

floppy usr usr

Consider a filesystem that is mounted on multiple places across the filesystem. This is a standard feature of Unix and Linux and can be achieved with the old framework discussed so far. Imagine the situation depicted in the top-left part of Figure 8-7: The directory /virtual contains three identical bind mounts of the root filesystem in /virtual/a, /virtual/b, and /virtual/c. However, it could be desirable that any medium mounted in /media will also be visible in /virtual/user/media, even if the medium was added after the mount structure has been established. The solution is to replace the bind mounts by shared mounts: In this case, any filesystem mounted in /media in any of the peers (/, /file/virtual/a/, /file/virtual/b/, and /file/virtual/c/) will be visible in all of them. The top-right part of Figure 8-7 shows the directory tree in this situation.

If the filesystem structure presented above is used as a basis for containers, each user of a container can see all other containers by looking at the contents of /virtual/name/virtual! Usually, this is not desired.16 A remedy to the problem is provided by turning /virtual into an unbindable subtree: Its contents can then not be seen anymore in bind mounts, and the users trapped in the containers will not see anything that lives outside their world. The bottom-left part of Figure 8-7 illustrates the situation.

16Note that many of the problems presented here can also be solved to some extent by using more refined variants of binding mounts or proper access control, but usually, some drawbacks or limitations will come along with these solutions. The possibilities offered by shared subtrees are usually more powerful.

Another issue arises when all container users are supposed to see devices mounted on /media, for instance, a USB stick in /media/usbstick. This clearly works if /media is shared between the containers, but has one drawback: Any container user will see the media mounted by any other container. Turning /media into a slave mount keeps the desired features (mount events propagating from /), but isolates the containers from each other. As the bottom-right part of Figure 8-7 shows, the camera mounted by user A cannot be seen in any other container, while the USB stick mount point propagates downward into all subdirectories of /virtual.

Recall that the data structures that are the basis for shared subtrees were described in Section 8.4.1. Let us thus now turn our attention to the required extensions of the mount implementation. If one of the flags MS_SHARED, MS_PRIVATE, MS_SLAVE, or MS_UNBINDABLE is passed to the mount system call, then do_mount calls do_change_type to change the type of a given mount. The function is essentially implemented as follows:

Continue reading here: Fsnamespacec

Was this article helpful?

0 0