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:   Tue, 22 Nov 2016 15:49:51 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Eric Biggers <ebiggers@...gle.com>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>,
        Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH] ext4: fix reading new encrypted symlinks on no-journal filesystems

On Nov 21, 2016, at 4:19 PM, Eric Biggers <ebiggers@...gle.com> wrote:
> 
> On Fri, Nov 18, 2016 at 02:52:22PM -0700, Andreas Dilger wrote:
>> 
>>> Yes, this would be a much nicer way to detect fast symlinks.
>>> 
>>> The only thing I'd be concerned about is the possibility of pre-existing
>>> "slow" symlinks that actually have targets short enough to be "fast"
>>> symlinks, perhaps in filesystems created by old drivers or by external
>>> tools.  If such links happened to work before, then a change to check
>>> i_size would break them.
>>> 
>>> This may not be an issue in practice.  I checked some old ext4 versions,
>>> ext2 from Linux 0.99.7, e2fsprogs, Android's ext4_utils, and FreeBSD's
>>> ext2 driver.  They all create "fast" symlinks if the length of the
>>> symlink target length excluding the terminating null (i_size) is < 60.
>> 
>> I did a similar analysis with similar results.
>> 
> 
> Ted, what would you say about Andreas' suggestion to use i_size to
> distinguish fast symlinks from slow symlinks?
> 
> It looks like this was discussed some years ago but the discussion died
> out and no change was made: see https://www.spinics.net/lists/linux-ext4/msg05693.html
> 
> Given the investigation I did it seems it would very likely be safe, but
> we can never be 100% sure it won't break some obscure tool or (version of
> a tool) to create symlinks on ext2/ext3/ext4 filesystems we don't know
> about.

Conversely, we've had fast symlinks break a few times due to additional
blocks being stored with the fast symlink (external xattr blocks for SELinux,
now encryption), possibly others in the future, and such breakages are
backwards incompatible (i.e. if there is some new way to add a block to
a symlink it will break all older kernels).

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ