Bug 830427 - CLONE_NEWNS does not work
CLONE_NEWNS does not work
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-09 09:23 EDT by Ulrich Drepper
Modified: 2012-06-11 07:59 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-11 07:59:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ulrich Drepper 2012-06-09 09:23:55 EDT
Description of problem:
The CLONE_NEWNS flag, both in clone() and in unshare(), seems not to have anything effect on the F16 kernels anymore.  It used to work but at least since 3.3.5-2 it doesn't.  Strangely enough, using the same 3.3.7-1 kernel on a F17 system it works.

Version-Release number of selected component (if applicable):
kernel-3.3.5-2, kernel-3.3.7-1

How reproducible:
always

Steps to Reproduce:
1.run as root: unshare -m /bin/bash
2.in the new shell: mount --bind /bin /mnt
3.from a different shell: "ls /mnt" and "cat /proc/mounts"
  
Actual results:
The directory bind is visible outside the "unshare" session

Expected results:
not visible

Additional info:
I really cannot explain why it works on F17 with the same kernel.  In the application I have there are more strange things happening wrt to mounting and none of the problems appear on the F17 machine.
Comment 1 Josh Boyer 2012-06-09 18:19:24 EDT
That is indeed odd, but I'm not even sure it is the result of the F16 vs. F17 3.3.7-1 kernel.  I have my machine running 3.3.7-1.fc16.x86_64 with F17 userspace and your testcase seems to work fine here:

[jwboyer@zod boot]$ sudo unshare -m /bin/bash
[root@zod boot]# uname -a
Linux zod.bos.redhat.com 3.3.7-1.fc16.x86_64 #1 SMP Tue May 22 13:59:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@zod boot]# date
Sat Jun  9 18:13:40 EDT 2012
[root@zod boot]# mount --bind /lib/modules /mnt
[root@zod boot]# ls /mnt
3.3.7-1.fc16.x86_64  3.3.7-1.fc17.x86_64  3.4.0-1.fc17.x86_64
[root@zod boot]# date
Sat Jun  9 18:14:11 EDT 2012
[root@zod boot]# umount /mnt
[root@zod boot]# ls /mnt
boot  home
[root@zod boot]#

(and in the other shell)


[jwboyer@zod linux-2.6]$ date 
Sat Jun  9 18:13:55 EDT 2012
[jwboyer@zod linux-2.6]$ uname -a 
Linux zod.bos.redhat.com 3.3.7-1.fc16.x86_64 #1 SMP Tue May 22 13:59:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[jwboyer@zod linux-2.6]$ ls /mnt
boot  home
[jwboyer@zod linux-2.6]$ 


I ran the same test with that specific kernel in an F16 VM and had the same results you did.  Perhaps there is an issue in util-linux?  I'm going to reassign to that for now.
Comment 2 Karel Zak 2012-06-11 04:58:03 EDT
man unshare (F17):
--
mount namespace

mounting and unmounting filesystems will not affect rest of  the  system  (CLONE_NEWNS  flag), except  for  filesystems  which  are explicitly marked as shared (by mount --make-shared). See /proc/self/mountinfo for the shared flags.
--


Please, check your /proc/self/mountinfo, especially the root filesystem. It's possible the the shared flag is set (for example) by /etc/init.d/sandbox. You have to set your /mnt as private (mount --make-private) or disable the sandbox.
Comment 3 Ulrich Drepper 2012-06-11 07:59:30 EDT
(In reply to comment #2)
 
> Please, check your /proc/self/mountinfo, especially the root filesystem.
> It's possible the the shared flag is set (for example) by
> /etc/init.d/sandbox. You have to set your /mnt as private (mount
> --make-private) or disable the sandbox.

That's indeed at least part of the story.  Sometime in the F16 lifetime this setting changed, the root filesystem has the shared bit explicitly set.  My program still doesn't work on F16 (it did in the past and does work on F17) but I will investigate it further.  Let's close this bug.

Note You need to log in before you can comment on or make changes to this bug.