Re: [vserver] Re: Nested mount namespaces

From: Grzegorz Nosek <grzegorz.nosek_at_gmail.com>
Date: Fri 10 Jun 2011 - 12:09:33 BST
Message-ID: <4DF1FB6D.9060106@gmail.com>

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
Received on Fri Jun 10 12:09:45 2011

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 10 Jun 2011 - 12:09:45 BST by hypermail 2.1.8