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: <CAAeU0aM-57TcFC2792zkZmXsUaUqajL72EWKUPAAxowSkuDYfg@mail.gmail.com>
Date:   Wed, 12 Jul 2017 14:36:23 -0700
From:   Tahsin Erdogan <tahsin@...gle.com>
To:     "Richard W.M. Jones" <rjones@...hat.com>,
        Andreas Dilger <adilger@...ger.ca>,
        "Theodore Ts'o" <tytso@....edu>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: Fast symlinks stored slow

>> 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.
>
> As a further data point, e2fsck does not complain about these
> filesystems.

This sounds bad. We may have to revert back to i_blocks based logic.

As an example, lets say inode's EXT4_INODE_EXTENTS flag is clear,
i_size is 2 and i_data[0] contains 0x00004141. Without inspecting
xattrs and i_blocks, we can't determine whether a) the target is "AA"
or b) block 0x4141 contains two bytes that is the actual symlink
target.