linux-ext4 - Re: State of dump utility

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: <20200930020646.GD23474@mit.edu>
Date:   Tue, 29 Sep 2020 22:06:46 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Lukas Czerner <lczerner@...hat.com>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: State of dump utility

On Tue, Sep 29, 2020 at 04:37:13PM +0200, Lukas Czerner wrote:
> 
> lately we've had couple of bugs against dump utility and a after a quick
> look at the code I realized that it is very much outdated at least on
> the extN side of things and would need some work and attention to make it
> work reliably with modern ext4 features.
> 
> However the code has been neglected for a while and talking to the
> maintainer he is pretty much done with it. At this point I am ready to
> pull the plug on dump/restore in Fedora, but before I do I was wondering
> whether there is any interest in moving dump/restore, or part of it, into
> e2fsprogs ?
> 
> I have not looked at the code close enought to say whether it's worth it
> or whether it would be better to write something from scratch. There is
> also a question about what to do with the tape code - that's not
> something I have any interest in digging into.
> 
> In my eyes dump had a good run and I would be happy just dumping it, but
> it is worth asking here on the list. Is there anyone interested in
> maintaining dump/restore, or is there interest in or objections agains
> merging it into e2fsprogs ?

One of the interesting questions is how reliable the dump utility
really is; that's because it works by reading the metadata directly
--- while the file system is mounted.  So it's quite possible for the
metadata to be changing out from under the dump/restore process.
Especially with metadata checksums, I suspect dump/restore is going
much more unreliable in terms of the libext2fs returning checksum
failures.

In the future, if we ever try to bypass the use of the buffer cache,
and instead have jbd2 write out directly to the bio layer so we cant
get better write error codes.  There was a discussion about this
recently, and there are two problems.  First, we need to worry about
programs like tune2fs and e2label that need to be able to read and
modify the superblock while the file system is modified.  We'd want to
add ioctl's to set and get the superblock, and update e2fsprogs to try
to use those system calls first.  And then.... there is dump/restore.i

I could imagine adding ioctl's which allow safe read-only access to
all metadata blocks, and not just for the superblock.  The question,
though is... is it worth it, especially if it's only to make
dump/restore work?

On the other hand, if we want to try to implement some kind of on-line
fsck work, then -perhaps safe metadata reading would be part of that
interface.  So I'd never say never, but I do wonder if it's time to
pull the plug on dump/restore --- especially if we want to allow it to
support not just inline files/directories, but also things like
extended attributes and ACL's.

						- Ted