linux-ext4 - Re: Corruption from interrupted e2fsck

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:	Mon, 2 Nov 2015 14:31:01 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: Corruption from interrupted e2fsck

> On Nov 2, 2015, at 8:23 AM, Theodore Ts'o <tytso@....edu> wrote:
> 
> On Sun, Nov 01, 2015 at 06:16:50PM -0700, Andreas Dilger wrote:
>> Is there a reason not to have a cancel check right after the return from
>> e2fsck_run() rather than trying to recover the journal and quota files?
>> I can imagine that there is a desire to flush out modified inodes and such
>> that have been repaired, so that restarting an interrupted e2fsck will make
>> progress, but the quota file update is plain wrong unless at least pass1
>> has finished, and the journal recreation is also dangerous if the block
>> bitmaps have not been fully updated.
> 
> You're right.  My suggested fix would be in the case of
> E2F_FLAG_CANCEL, we set the ctx->invalid_bitmaps flag, and then avoid
> writing out the quota file if invalid_bitmaps is enabled.

I was looking at that too.  In some sense it isn't a bad idea to allow
updating the quota file in this case, but it still bothers me that e2fsck
would continue on to update the quotas if the user wants to kill it, so
my preference would be to not write the quota files at all if e2fsck is
interrupted.

It would probably make more sense to have an option like "-E quota-only"
to allow running a shorter e2fsck (maybe useful for link-farm backups
that take a long time in later passes) but most of the time pass 1 is
the slowest so there is usually minimal benefit from skipping later passes.

Cheers, Andreas

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