Am 01.03.2015 um 09:02 schrieb Corey Wright:
> On Sun, 22 Feb 2015 16:50:00 +0100
> Oliver Welter <mail@oliwel.de> wrote:
>
>> 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.
>
> thanks for debugging it to the point of identifying CAP_SYS_ADMIN, which
> was the pertinent piece of information, but the character devices were a
> red herring [1] (partially because of my confusion in how and when they are
> used in overlayfs).
>
> vattribute --set --xid ${VS_XID} --ccap ^3
> OR
> echo ^3 >>/etc/vservers/${VS_NAME}/ccapabilities
>
> (or "fs_trusted", instead of "^3", once daniel merges this [2].)
corey, many thanks for digging into that - I can confirm that adding
fs_trusted to ccaps make my guest setup work. Even if you said that it
should not have any side effects on security, I would appreciate if you
can implement one of the suggested approaches to the kernel so it not
necessary.
As soon as I got my broken RAID array fixed - :( - I will try this
approach on some not-so-critical-but-production systems and hope it blends.
best regards
Oli
-- Protect your environment - close windows and adopt a penguin!