linux-kernel - Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

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: <1217979862.2887.39.camel@luna.unix.geek.nz>
Date:	Wed, 06 Aug 2008 11:44:22 +1200
From:	Jasper Bryant-Greene <jasper@...ton.co.nz>
To:	Dave Chinner <david@...morbit.com>
Cc:	Karel Zak <kzak@...hat.com>, Christoph Hellwig <hch@....de>,
	linux-kernel@...r.kernel.org, xfs@....sgi.com,
	util-linux-ng@...r.kernel.org
Subject: Re: XFS noikeep remount in 2.6.27-rc1-next-20080730

On Wed, 2008-08-06 at 09:39 +1000, Dave Chinner wrote:
> We're seeing the second case where mount is merging all the options in
> /etc/fstab into the options passed into the remount command. How is
> the filesystem expected to behave in these difference cases? The
> first simply changes the ro/rw status, the second potentially
> asks for the filesystem to change a bunch of other mount options
> as well, which it may not be able to do.
> 
> So what is the correct behaviour? Should the filesystem *silently
> ignore* unchangable options in the remount command, or should it
> fail the remount and warn the user that certain options are not
> allowed in remount?

(forgive me, I'm an XFS user, not an XFS developer, so this might be
ignorant)

The filesystem presumably knows what options it was originally mounted
with.

Thus if you take the difference of the set of options you were mounted
with, and the set of options you are now being asked to remount with,
you have the options which are being asked to change.

If changing any of them is unsupported I would expect an error, but in
this case the result of taking the above set difference would be merely
replacing ro with rw, and thus the filesystem is presumably capable of
doing the remount.

-jasper

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