linux-ext4 - Re: Ideas on unified real-ro mount option across all filesystems

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:	Fri, 18 Dec 2015 05:20:18 +0100
From:	Christoph Anton Mitterer <calestyo@...entia.net>
To:	Eric Sandeen <sandeen@...deen.net>,
	Qu Wenruo <quwenruo@...fujitsu.com>,
	Eric Sandeen <sandeen@...hat.com>,
	fsdevel <linux-fsdevel@...r.kernel.org>,
	btrfs <linux-btrfs@...r.kernel.org>, kzak@...hat.com
Cc:	linux-ext4@...r.kernel.org, xfs@....sgi.com
Subject: Re: Ideas on unified real-ro mount option across all filesystems

On Thu, 2015-12-17 at 20:51 -0600, Eric Sandeen wrote:
> >    -r, --read-only
> >        Mount the filesystem read-only.  A synonym is -o ro.
> > 
> >        Note  that,  depending  on the filesystem type, state and
> >        kernel behavior, the system may still write to the
> > device.  For
> >        example, ext3 and ext4 will replay the journal if the
> >        filesystem is dirty.  To prevent this kind of write access,
> > you
> >        may want to mount an ext3 or ext4 filesystem with the
> > ro,noload
> >        mount options or set the  block  device itself to read-only
> >        mode, see the blockdev(8) command.
> 
> which should leave nothing to the imagination.
hmm apparently Debian sid's mount(8) is a bit outdated, but anyway,
this just means that the behaviour of "ro" is not properly (end-user-
friendly) documented. :-)

I still see basically the following left:
a) Could filesystems benefit from knowing that they shouldn't write to
   the device (e.g. by spitting out less errors or that like)?
b) Or does each filesystem auto-detect, that the blockdev is "ro" and
   does handle accordingly?
c) Are there other cases left, where using blockdev --setro may be a
   worse solution to having a dedicated mount option for "hard ro"?

If only (b) would apply, then the state as is seems fine, and pointing
people to blockdev --setro would be enough.
But would (b) work in case of multi-dev fs, where e.g. some can be ro
(perhaps seed devices) while others can be rw?

If (a) would apply, then it would IMHO still make sense to have
dedicated "hard ro" mountoption. The above manpage snipped would
already show that it names "noload", but this is only for ext* and as
I've said before, manpages which can easily be out of date, may not
list all options that are required by then, especially not for each fs.

If (c) would apply, then I think for the same reasons, having a
dedicated mount option would be beneficial.

Examples I can think of:
btrfs with multidevices.
Imagine you have a big box with some 100 disks, and multiple multi-
device btrfs filesystems on these.
One goes bad, and you want to start with recovery or forensics, but
that fs comprised of 34 devices (thus it's not easy to do this on some
other node).
Do we really want to let people start to call --setro on these 34
devices (maybe some of them are multipath) and perhaps even
accidentally setting the wrong device ro, thereby causing damage to
live filesystem?
It would be much simpler if one had a mount option, wouldn't it.

Well just some thoughts, though.

Cheers,
Chris.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5313 bytes)