Subject: Re: [vserver] Re: Nested mount namespaces
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Fri, 10 Jun 2011 13:38:24 +0200

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