.in
.RE
.IP
-The above steps, performed in a more privileged user namespace,
+The above steps, performed in a more privileged mount namespace,
have created a (read-only) bind mount that
obscures the contents of the directory
.IR /mnt/dir .
For security reasons, it should not be possible to unmount
-that mount in a less privileged user namespace,
+that mount in a less privileged mount namespace,
since that would reveal the contents of the directory
.IR /mnt/dir .
.IP
The new mount namespace will inherit copies of all of the mounts
from the previous mount namespace.
However, those mounts will be locked because the new mount namespace
-is owned by a less privileged user namespace.
+is owned by a less privileged mount namespace.
Consequently, an attempt to unmount the mount fails:
.IP
.RS
the mount is locked.
.IP *
Following on from the previous point,
-note that it is possible to unmount an entire
-tree of mounts that propagated as a unit into a mount namespace
-that is owned by a less privileged user namespace,
+note that it is possible to unmount an entire tree of mounts that
+propagated as a unit into a less privileged mount namespace,
as illustrated in the following example.
.IP
First, we create new user and mount namespaces using
.in
.IP
Continuing in the same shell session,
-we then create a second shell in a new mount namespace and a new subordinate
-(and thus less privileged) user namespace and
+we then create a second shell in a new user namespace and a new
+(less privileged) mount namespace and
check the state of the propagated mount points rooted at
.IR /mnt .
.IP