On Thu, Jun 09, 2011 at 05:30:05PM +0200, Grzegorz Nosek wrote:
> W dniu 09.06.2011 16:46, Grzegorz Nosek pisze:
>> Using ns_exec -c -m (or ns_exec -m) also reports successful
>> unshare/clone but changes to mounts remain visible.
> Running the same test from the host gives expected behaviour,
> i.e. mounts changed from the shell spawned via ns_exec are not
> visible to other processes.
might have several reasons:
- unshare actually fails despite reporting success
- the two namespaces used in a typical guest setup
(with AFAIK shared mounts) cause unwanted behaviour
- the test process is flawed
> VServer version is 188.8.131.52-vs184.108.40.206.33, util-vserver
updating to a more recent kernel would be advised
> BTW2: I'm not clear about how ccaps are supposed to work.
> I'd understand that a guest without CAP_SYS_ADMIN but _with_
> VXC_NAMESPACE should be able to call unshare but apparently
> it isn't so (-EPERM).
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
> 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
> Best regards, Grzegorz Nosek
Received on Fri Jun 10 11:23:36 2011