linux-kernel - Re: [GIT PULL] overlayfs fixes for 4.9-rc3

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] [day] [month] [year] [list]

Date:   Sat, 5 Nov 2016 22:41:16 +0100
From:   Peter Rosin <peda@...ntia.se>
To:     Miklos Szerendi <miklos@...redi.hu>
CC:     <linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
        <linux-unionfs@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Amir Goldstein <amir73il@...il.com>
Subject: Re: [GIT PULL] overlayfs fixes for 4.9-rc3

> And the thing is, backward incompatibility is less of an issue for
> overlayfs than for normal filesystems, because it's usually not
> something people store their root filesystems on, and if so they can
> simply not turn off this feature.

That got my attention. What backwards incompatible thing is it that
I simply cannot turn off for the overlayfs that I use as root fs?
Now, we don't boot straight into the overlay as root fs, buy we do
pivot it in early enough. If you are somehow suggesting that
overlayfs as root fs is not something that needs considering you
need to think again. We depend on it, and I will flag any regression
that we are walking into.

But hopefully you just messed up the negations, and you meant that we
*can* simply turn <whatever> off?

Cheers,
Peter

[I hope threading works, got the message-id from an archive]