Description of problem: Mounting a filesystem in a child mount namespace created with "unshare -m" results in a mount that is visible in the parent. Version-Release number of selected component (if applicable): # rpm -q util-linux util-linux-2.20.1-2.2.fc16.x86_64 # rpm -q kernel kernel-3.2.3-2.fc16.x86_64 How reproducible: 1. unshare -m /bin/bash 2. (in the child) mount -t tmpfs tmpfs /mnt 3. (in the parent) ls /mnt Actual results: The contents of /mnt in the parent are masked by the mount in the child namespace. Expected results: The mount in the child namespace will not affect the parent namespace. Additional info: I have two systems running identical kernels and identical userspace tools. One system experiences this bug as described, the other works as expected. ON THE WORKING SYSTEM ===================== In the parent namespace: # grep /mnt /proc/self/mountinfo # ls /mnt file1 file2 file3 # unshare -m /bin/bash In the child namespace: # mount -t tmpfs tmpfs /mnt # ls /mnt # grep /mnt /proc/self/mountinfo 72 44 0:35 / /mnt rw,relatime - tmpfs tmpfs rw In the parent namespace: # ls /mnt file1 file2 file3 # grep /mnt /proc/self/mountinfo # ON THE PROBLEM SYSTEM ===================== In the parent namespace: # grep /mnt /proc/self/mountinfo # ls /mnt file1 file2 file3 # unshare -m /bin/bash In the child namespace: # mount -t tmpfs tmpfs /mnt # ls /mnt # grep /mnt /proc/self/mountinfo 83 51 0:40 / /mnt rw,relatime shared:4 - tmpfs tmpfs rw In the parent namespace: # ls /mnt # grep /mnt /proc/self/mountinfo 84 22 0:40 / /mnt rw,relatime shared:4 - tmpfs tmpfs rw # On the problem system I can make things behave as expected by running, before "unshare": # mount -o bind /mnt /mnt # mount --make-private /mnt But it's not clear why this is necessary on one system but not the other.
Upon further investigation (http://unix.stackexchange.com/questions/31050/problem-with-mount-namespaces-under-fedora) it looks like this is due to the "sandbox" init script installed by the policycoreutils package. The "problem" system is a desktop system, which includes the sandbox script enabled in runlevel 5, whereas the "working" system is a headless server, so it does not run the sandbox script. This represents a fairly substantial difference in behavior, and I wonder if there's not some way to make the behavior of the sandbox script more explicit, or tied more tightly to the services that require it -- that is, instead of running it by default, run it only if the user is using xguest, pam_namespace, etc. It seems like most of those tools could look at the entry for "/" in /proc/self/mountinfo and see if it has the "shared" flag.
This is known sandbox behaviour. If you want to be really sure that your mounts are unshared independently on the current system setting then call mount --make-private <mnt>. I have added a comment about MS_SHARED flag (mount --make-shared) to the man page unshare.1 to make it more obvious for users. [Upstream commit bc87f885125d6d7bd9f353cf78d79a56a882f51b, the man page update will be available in Fedora 17.]
(In reply to comment #1) > This represents a fairly substantial difference in behavior, and I wonder if > there's not some way to make the behavior of the sandbox script more explicit, > or tied more tightly to the services that require it -- that is, instead of > running it by default, run it only if the user is using xguest, pam_namespace, > etc. Good point, reassigning...
sandbox init script is no longer needed in F17. Not really sure it is needed in F16 any more.
Just following up on old reports...can we declare this WONTFIX, or close the ticket, or something?