Re: Remount root RO after the root dentry drops from the namespace

[Karel Zak <kzak@redhat.com>]

On Wed, Nov 18, 2009 at 04:28:23PM +0100, Miklos Szeredi wrote:
> On Wed, 18 Nov 2009, Karel Zak wrote:
> >  The "flags" argument of mount(2) always contains MS_BIND for bind
> >  mounts (if you use standard mount(8) command and /etc/mtab) for -o
> >  remount.
> 
> I think that's a bug.  I can see the reasoning behind it, but it's

 Don't blame userspace :-) see kernel patch:

 commit 2e4b7fcd926006531935a4c79a5e9349fe51125b
 Author: Dave Hansen <haveblue@us.ibm.com>
 Date:   Fri Feb 15 14:38:00 2008 -0800

 [PATCH] r/o bind mounts: honor mount writer counts at remount

> wrong.  mount(8) should not guess whether the user wants to change the
> per superblock flags or the per mount flags based on *how* the mount
> was created.
> 
> Look:
> 
>   mount /dev/hda1 /mnt1; mount /dev/hda1 /mnt2
> 
> is completely equivalent to
> 
>   mount /dev/hda1 /mnt1; mount --bind /mnt1 /mnt2
> 
> Why should "mount -oremount" treat one differently than the other?

 It's kernel who cares about M_REMOUNT & MS_BIND. And kernel
 MS_REMOUNT behavior was silently changed one year ago.
 
 The mount(8) command has exactly defined way how works with mount
 options for many years. There is not any exception for MS_BIND. It
 reads options from fstab/mtab and apply options from command line,
 the result is send to kernel.

 I think the current (undocumented:-) kernel behavior is not clear.
 We use two options for three separate operations: MS_REMOUNT (remount
 superblock), MS_BIND (loopback) and MS_REMOUNT & MS_BIND (change mnt
 flags).

> It would be much cleaner to have a mount option, say
> --change-mnt-flags, that is equivalent to "--bind -oremount".

 Maybe, the question is how many users already depend on mount --bind
 /old /new; mount -o remount,ro /new.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>