linux-kernel - Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 21 Oct 2016 11:30:04 +0200
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Vivek Goyal <vgoyal@...hat.com>,
        "linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Jeremy Eder <jeder@...hat.com>,
        David Howells <dhowells@...hat.com>,
        Gou Rao <grao@...tworx.com>, Vinod Jayaraman <jv@...tworx.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Dave Chinner <david@...morbit.com>
Subject: Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up

On Fri, Oct 21, 2016 at 11:13 AM, Amir Goldstein <amir73il@...il.com> wrote:

> I think it would be a good idea in general to stabilize the overlay ino/dev
> throughout copy-up, same as Miklos suggested to do for directories, to
> all files:
> pure upper uses upper ino + overlayfs dev
> non-pure upper uses lower ino + overlayfs dev

Making st_ino, st_dev and d_ino behave consistently would be the next big step.

The above scheme only works if lower and upper are on the same
filesystem.  Otherwise there can be collisions between the lower and
upper inode numbers.  Perhaps you meant:

- pure upper uses upper ino + upper dev
- non-pure upper uses lower ino + overlayfs dev

It works for the single lower layer case, but again breaks if there
are multiple lower layers.   And d_ino in a merged directory could
still get us into trouble.  And find -xdev would not do what you'd
expect with a "normal" filesystem.

So there doesn't appear to be any easy solutions to this...

Thanks,
Miklos