linux-kernel - Re: Add a norecovery option to ext3/4?

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: <461BE2FB.5090101@redhat.com>
Date:	Tue, 10 Apr 2007 14:18:19 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Phillip Susi <psusi@....rr.com>
CC:	Samuel Thibault <samuel.thibault@...-lyon.org>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
	joern@...ybastard.org, tytso@....edu
Subject: Re: Add a norecovery option to ext3/4?

Phillip Susi wrote:
> Eric Sandeen wrote:
>> It means the filesystem should not be writeable when it is mounted.
>> This is not the same as saying that the filesystem itself should do no
>> IO in the course of making that read-only mount available.
> 
> I disagree.
> 
>> I respectfully disagree, see above.
> 
> Based on what?  I argue that historically the primary use of the read 
> only mount flag was to prevent the underlying filesystem from being 
> modified and possibly damaged further before it can be fsck'ed.  It 
> became common practice to mount the root filesystem read only and run a 
> fsck on it, then either reboot or remount read-write depending on if 
> fsck had to make changes.

except in the case of a journaling filesystem, where the journal in
theory obviates the need for a fsck.  (yes, I know... fsck still has a
place...)  But, fsck is largely meaningless until the journal has been
recovered anyway (fs can only be consistent if it includes uncommited
transactions in the journal), so isn't this new territory?

I guess looking to the man page for clarification of intent is no help...

              ro  Mount the file system read-only.

> In this context, the meaning of the read only mount flag was clear: do 
> not write to the disk.  If you wish to redefine it as "do not allow me 
> write access to any files" then you fly in the face of convention, and 
> the onus is on you to provide a compelling argument to make such a change.

I'm admittedly playing devil's advocate here :)  but what, in the
historical non-journalled filesystem case, would be writing to the
device anyway, if all IO from the vfs were stopped?  Without the
journal, isn't vfs-ro the same as bdev-ro, largely?

As a counter example, if you had a filesystem which saves it's last
mount time in the superblock; should a ro mount not update that time?
(perhaps not, depending on how that timestamp was intended to be used.)

>> In that case you are mounting the same filesystem uner 2 different
>> operating systems simultaneously, which is, and always has been, a
>> recipe for disaster.  Flagging the fs as "mounted already" would
>> probably be a better solution, though it's harder than it sounds at
>> first glance.
> 
> No, it has not been.  Prior to poorly behaved journal playback, it was 
> perfectly safe to mount a filesystem read only even if it was mounted 
> read-write by another system ( possibly fsck or defrag ).  You might not 
> read the correct data from it, but you would not damage the underlying 
> data simply by mounting it read-only.

You might not damage the underlying filesystem, but you could sure go
off in the weeds trying to read it, if you stumbled upon some
half-updated metadata... so while it may be safe for the filesystem, I'm
not convinced that it's safe for the host reading the filesystem.

>> Under all conditions it should be safe to mount a read-only block
>> device, but that is not the same as mounting a filesystem read-only.
> 
> Historically it was the same thing.  I see no reason to change that 
> behavior, do you?

but it's already changed, and has been in linux since ext3 came on the
scene.  mount -o ro -does- replay the journal.  Surely readonly does not
imply that we want a corrupted filesystem if it was not cleanly shut
down.  I suppose there is a place for the argument that a readonly mount
of a journaled filesystem -should- present a recovered filesystem to the
user, without actually recovering the log to disk.  I guess to me, it
hardly seems worth the effort, as the precedent is long set for doing
recovery on a read-only mount.

-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/