Subject: Re: [vserver] Issue with OverlayFS in 3.18
From: Oliver Welter <mail@oliwel.de>
Date: Sun, 22 Feb 2015 16:50:00 +0100
Sun, 22 Feb 2015 16:50:00 +0100
Am 22.02.2015 um 15:50 schrieb Oliver Welter:
> Hi Bertl,
>
> Am 02.02.2015 um 11:11 schrieb Herbert Poetzl:
>> On Mon, Feb 02, 2015 at 08:10:15AM +0100, Oliver Welter wrote:
>>> Am 02.02.2015 um 01:58 schrieb Herbert Poetzl:
>>>> On Sun, Feb 01, 2015 at 03:28:22PM +0100, Oliver Welter wrote:
>>
>>>>> Trying the same without starting the vserver, using a simple
>>>>> "chroot" works, so it looks like some limits are not working
>>>>> correctly.
>>
>>>> Please try without Linux-VServer isolation but with the same
>>>> namespace setup, I don't think that you are hitting a limit
>>>> here, it looks more like a namespace problem of overlayfs.
>>
>>> Can you be a bit more verbose - I never git in touch with the
>>> individual components ;)
>>
>> Either use vnamespace or the unshare tool to create a namespace
>> setup identical to your guest and check if the issue remains.
>
> I am unable to reproduce it with vnamespace or unshare, I used attached
> test script and ran it as:
>
> vnamespace -n /mnt/test.sh
> vcontext --create --xid 42 /mnt/test.sh
> unshare  -i -m -u test.sh
>
> with the correct result (file breakme is replaced by a directory on the
> common mount).
>
> When you do the same inside a vserver, it does not work (use overlay to
> assemble rootfs of vserver, start vserver, try to change entity which
> exists on the lower but not on the upper fs).
>
I think I got the root cause - overlayfs uses character files to mark 
whiteouts and the vserver env seems to refuse access to this whiteout 
file. Adding SYS ADMIN "makes it work", so I guess the right way would 
be to skip the access check for overlayfs whiteouts.

Oli



-- 
Protect your environment -  close windows and adopt a penguin!



["application/pkcs7-signature" not shown]