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: <461BDD48.2000904@cfl.rr.com>
Date:	Tue, 10 Apr 2007 14:54:00 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Eric Sandeen <sandeen@...hat.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?

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.

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.

> 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.

> 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?

-
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/