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: <20151217140858.GD13224@ws.net.home>
Date:	Thu, 17 Dec 2015 15:08:58 +0100
From:	Karel Zak <kzak@...hat.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Qu Wenruo <quwenruo@...fujitsu.com>,
	fsdevel <linux-fsdevel@...r.kernel.org>,
	btrfs <linux-btrfs@...r.kernel.org>, linux-ext4@...r.kernel.org,
	xfs@....sgi.com
Subject: Re: Ideas on unified real-ro mount option across all filesystems

On Wed, Dec 16, 2015 at 09:15:59PM -0600, Eric Sandeen wrote:
> I have always interpreted it as simply "no user changes to the filesystem,"
> and that is clearly what the vfs does with the flag...

Yep,

> Given that nothing in the documentation implies that the block device itself
> must remain unchanged on a read-only mount, I don't see any problem which
> needs fixing.  MS_RDONLY rejects user IO; that's all.

I agree, it's FS specific business to interpret the 'ro'.

And it's already enough complicated, we have three levels of "read-only":

 - read-only device (blockdev --setro ioctl)
 - read-only filesystem (mount -o ro)
 - read-only VFS node (mount -o remount,ro,bind /src /dst)

and for example in /proc/self/mountinfo we distinguish between FS "ro"
and VFS "ro" flag:

# grep test /proc/self/mountinfo
185 59 8:5 / /mnt/test ro,relatime shared:32 - ext4 /dev/sda5 rw,data=ordered
                       ^^                                     ^^


BTW, util-linux 2.27 mount(8) man page:

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


 (maybe we need to copy this note to "ro" description too and add hint
 about btrfs too :-)

     Karel


-- 
 Karel Zak  <kzak@...hat.com>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ