W dniu 10.06.2011 12:23, Herbert Poetzl pisze: > might have several reasons: > > - unshare actually fails despite reporting success It does succeed (a new namespace and nsproxy are created). > - the two namespaces used in a typical guest setup > (with AFAIK shared mounts) cause unwanted behaviour OK, I think I get it now. After making ~/foo a mountpoint by itself (via mount --bind foo foo before starting the test) I finally get the expected result. So apparently util-vserver started to use shared mounts between r2772 and r2926. Sigh. > - the test process is flawed The test process is as follows: shell1:~# mkdir -p foo/bar/baz shell2:~# find foo foo/ foo/bar/ foo/bar/baz/ shell1:~# ./ns_exec -m /bin/bash # unshare(CLONE_NEWNS) && exec() [ns]shell1:~# mount --bind foo/bar/baz foo [ns]shell1:~# find foo foo/ shell2:~# find foo # <- *** PROBLEM *** foo/ [ns]shell1:~# umount foo shell2:~# find foo foo/ foo/bar/ foo/bar/baz/ >> VServer version is 2.6.35.8-vs2.3.0.36.33, util-vserver >> 0.30.216-pre2926. > > updating to a more recent kernel would be advised Is that general advice or are there any serious known bugs with that patch version? The machine is in a _very_ remote DC and in case the upgrade fails for some reason it's going to be a PITA to bring back up. Anyway, what's the _recommended_ (as in, at least somewhat proven) kernel+patch combo now? > that behaviour is correct, but in recent kernels/patches > you can set the umask (unshare mask) which controls what > namespaces can be unshared inside a guest without actually > having CAP_SYS_ADMIN assigned to the guest How? >> Or, if they worked the other way around, CAP_SYS_ADMIN without >> VXC_NAMESPACE should prevent unshare but does not. >> Am I missing something? > > the VXC checks are usually done by vx_capable() > which looks like this: > > #define vx_capable(b, c) (capable(b) || \ > (cap_raised(current_cap(), b)&& vx_ccaps(c))) > > which in turn means, either you _have_ the bcap > inside the guest, or you _would_ have it without > the masking and the ccap is enabled > > now what does that mean in your case? > > guest has user has vx_capable() > CAP_SYS_ADMIN VXC_NAMESPACE CAP_SYS_ADMIN with both > -------------------------------------------------------------- > whatever whatever no no > no no yes no > yes whatever yes yes > whatever yes yes yes > > but VXC_NAMESPACE is probably a misnomer nowadays, as it is > only checked in do_change_type() which affects mount point > changes and nothing else What I'm seeing as root in the guest with the following caps (shell after vserver enter): CapInh: 0000000000000000 CapPrm: ffffffffffffffff CapEff: ffffffffffffffff CapBnd: ffffffffffffffff is: CAP_SYS_ADMIN VXC_NAMESPACE unshare(CLONE_NEWNS)==0 yes whatever yes no whatever no Best regards, Grzegorz Nosek