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!