On Fri, Jun 10, 2011 at 01:09:33PM +0200, Grzegorz Nosek wrote: > 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? the latest 2.6.38.x seems to be fine and should be somewhat proven by 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? not with your kernel, i.e. requires the latest 2.6.38.x as the feature was not enabled before >>> 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 because, as I tried to explain, VXC_NAMESPACE has no business or relation with unshare() :) best, Herbert > Best regards, Grzegorz Nosek