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
| ||
|
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.
Powered by blists - more mailing lists