Am 01.07.2013 13:22, schrieb Daniel P. Berrange:
On Mon, Jul 01, 2013 at 01:05:23PM +0200, Richard Weinberger wrote:
> 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