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  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:   Wed, 6 Mar 2019 11:48:46 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Artem Blagodarenko <artem.blagodarenko@...il.com>
CC:     <linux-ext4@...r.kernel.org>, <adilger.kernel@...ger.ca>
Subject: Re: [PATCH v7 1/4] ext2fs: opening filesystem code refactoring

On Tue, Jan 29, 2019 at 08:51:31PM +0300, Artem Blagodarenko wrote:
> There are similar opening filesystem code in different utilities.
> 
> The patch moves improved handling from try_open_fs()
> into ext2fs_open(). This function make one of the action
> based on parameters:
> 1) open filesystem with given superblock, superblock size
> 2) open filesystem with given superblock, but try to
> find right block size

This changes the behavior of ext2fs_open() when the superblock and
blocksize parameters is zero.  Previously we read the primary
superblock at the known location, and a blocksize of zero means "don't
care" and so we just do the right thing.  With your patch, it's going
to loop for all possible block sizes, failing with
EXT2_ET_UNEXPECTED_BLOCK_SIZE, until we stumble on the correct file
system.  That's unfortunate, especially if the device is opened with
IO_FLAG_DIRECT_IO.

So the brute force searching should be done using if an explicit flag
is given.  Using a new flag to request this new behavior is safer, but
it's probably OK if we only do the blocksize search if the superblock
parameter is zero --- you'll note that's what the code you were
replacing in dumpe2fs and e2fsck was doing.

More generally, for this whole patch series, in the "happy case" where
the file system is fine, e2fsck and e2image should *not* do any extra
work.

						- Ted

Powered by blists - more mailing lists