linux-kernel - Re: 45aebeaf4f67 "ovl: Ensure upper filesystem supports d

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 May 2016 08:39:08 +1000
From:	Daniel Axtens <dja@...ens.net>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-unionfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, mpe@...erman.id.au,
	mszeredi@...hat.com, dchinner@...hat.com
Subject: Re: 45aebeaf4f67 "ovl: Ensure upper filesystem supports d_type" breaking Docker

Hi Vivek,

Sorry for the delay in getting back to you.


> What't the underlying fs you are using. overlayfs requires underlying
> filesystem to support d_type and there were cases where xfs was
> built with ftype=0 and in that case xfs does not support d_type. That
> means it led to issues like whiteouts not being recognized and being
> left behind during various operations.

I'm using ext4 as the backing filesystem for Docker.

However, if I manually mount an overlay directly on the ext4 fs, it
works just fine.

Therefore, I suspect the problem arises through some magic Docker is
doing. I think it is layering overlays and may be doing that in some
weird way.

I'm hopefully going to get some more time to spend on this problem (and
on that machine) today. As soon as I can unpick what Docker is doing
I'll post more details.

Regards,
Daniel

>
> So it became clear that we need a check at mount time to make sure
> d_type is supported otherwise error out. This will require users to
> do mkfs.xfs with ftype=1 to make progress.
>
> I think new defaults for mkfs.xfs are such that ftype=1 is set. I am
> not sure which version that change was made in.
>
> Thanks
> Vivek
>
>> Reverting 45aebeaf4f67 ("ovl: Ensure upper filesystem supports d_type")
>> fixes the issue for me. I haven't investigated the root cause yet - at a
>> guess I'd say either Docker's layering system, or some weird interaction
>> with namespacing, maybe? I'll have a look when I get a spare moment.
>> 
>> For reference, I'm using docker 1.11.0-dev.
>> 
>> Regards,
>> Daniel Axtens