[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace



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

-ENOATTACHMENT :-(

Thanks,
//richard


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]