linux-ext4 - Re: Fast symlinks stored slow

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]

Message-ID: <20170713080213.GO31999@redhat.com>
Date:   Thu, 13 Jul 2017 09:02:13 +0100
From:   "Richard W.M. Jones" <rjones@...hat.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org, Tahsin Erdogan <tahsin@...gle.com>
Subject: Re: Fast symlinks stored slow

On Wed, Jul 12, 2017 at 07:17:37PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 12, 2017 at 06:07:11PM +0100, Richard W.M. Jones wrote:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1470157
> > 
> > To cut a long story short, we were using libext2fs to create
> > filesystems where short symlinks (< 60 bytes) were stored the same way
> > as long symlinks, ie. stored as an ordinary file instead of being
> > stored in the inode.
> > 
> > I think the reason we were creating filesystems wrongly in the first
> > place is because our code has been around since about 2008, and the
> > nice ext2fs_symlink function that deals properly with fast/slow
> > symlinks wasn't added until 2013.
> 
> Thanks for the report.  I had been hesitant about making this change
> (and had been pushing back from those who were advocating for this
> change) precisely because I was afraid that this might be a situation.
> 
> What convinced me to accept the change is that (a) I had scanned all
> of the old kernels and old versions of e2fsprogs and convinced myself
> that aside from someone manually creating symlinks using low-level
> libext2fs, symlinks < 60 bytes would never be stored in external
> blocks, and (b) using the i_blocks logic to determine whether or not
> we had a slow link was getting really painful.
> 
> > It's not too much trouble for us to recreate the incorrect
> > filesystems.  Mostly we're creating one-off throwaway filesystems for
> > appliances anyway and they don't live for long.
> > 
> > But I suppose this might be a warning that other incorrect filesystems
> > exist which will break with Linux >= 4.13.
> 
> So I see this is going to break libvert and libguestfs.  So people who
> are running existing distribution userspaces and then upgrade to 4.13
> will break.
> 
> Hmm...  I suppose we could add back support to let the kernel to use
> the i_blocks logic if the ea_inode feature is not enabled.  E2fsck
> would still complain so we can try to gradually force userspace to do
> things "correctly", but at least we would be backwards compatible.
> 
> Comments?

>From my point of view it's not too much trouble to recreate these
filesystems, and we've already proposed a fix for supermin so it
creates symlinks properly[1].

I think it might be a good idea to get e2fsck to complain about these
filesystems though.  It'll at least tell you how widespread (or
otherwise) the problem might be.

Rich.

[1] https://www.redhat.com/archives/libguestfs/2017-July/msg00084.html

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org