Am 01.07.2013 12:33, schrieb Daniel P. Berrange:
> On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote:
>> Any ideas what's going on here?
>
> No, it is very odd. It smells like a kernel issue to me. What
> version are you running ?
I see this issue on all kernels.
Currently I'm using vanilla v3.9.x and v3.10.
> I've also tried running the demo programs shown on the
LWN.net
> article
>
>
https://lwn.net/Articles/532593/
>
> and they don't operate in the way described by the article - the demo
> programs continue to ru as 'nfsnobody' even after the mappings are
> setup.
>
> I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled
> in KConfig. I'm wondering if there is still stuff missing in 3.9.x
> that prevents this from working properly, or if the kernel behaviour
> changed after those LWN articles were written.
To me it looks like the capability system behaves odd.
The mappings in /proc are fine as long I do not call capng_updatev().
Also calling capng_updatev() with parameters that do not change the current cap set
triggers the odd behavior too.
So we see two (related?) issues:
1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files till we
exec().
2. Dropping capabilities does not work we always gain a fresh and full capability set.
BTW: I'm sure the issues are not caused by Gau Feng's userns patches.
Yeah, I've reproduced this problem with standalone code outside of
libvirt.
Take the attached code and run
# gcc -Wall -o userns_child_exec userns_child_exec.c
# ./userns_child_exec -U -M '0 1000 1' -G '0 1000 8' bash
Launching child init
# id
uid=0(root) gid=7(lp) groups=0(root),65534(nfsnobody)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# ls -al /proc/1/environ
-r--------. 1 nfsnobody nfsnobody 0 Jul 1 12:14 /proc/1/environ
# cat /proc/1/environ
cat: /proc/1/environ: Permission denied
and this demo program isn't attempting to touch capabilties at all.
Daniel
--
|: