On Wed, Jul 12, 2006 at 11:17:09AM -0700, Dave Hansen wrote:
> Tries to incorporate comments from Al:
> http://article.gmane.org/gmane.linux.kernel/421029
>
> Al wrote:
> > b) figuring out what (if anything) should be done with
> > propagation when we have shared subtrees... (not trivial at all)
>
> Talked with Ram: Shared subtrees are about having identical views
> into the filesystem. Changing the mount permissions doesn't affect
> the view of the filesystem, so it should not be propagated.
I think shared subtrees propagates mount/unmount events only.
This is a case where we are just changing the access permission
for a mount instance. So it should not be treated as a propagation event.
Lets say we propagated the event. In that case we would end up with a
awkward situation.
1) mount --make-shared /mnt
2) mount --bind /mnt /tmp
3) mount --make-slave /tmp
4) mount -o remount,rw /tmp
5) mount -o remount,ro /mnt
In step (5) all of a sudden the mount at /tmp which was readwrite will
be downgraded to read-only. There must have been a reason why /tmp was
mounted rw in the first place. Also there would be no way for /mnt to be
made 'ro' without effecting /tmp.
Hence I feel the readwrite semantics must be decoupled from the
sharedsubtree semantics,
RP
>
> The things that probably need the heaviest review in here are the
> i_nlink monitoring patch (including the inode state flag patches 03
> and 06) and the new MNT_SB_WRITABLE flag (patch 05).
>
> ---
>
> The following series implements read-only bind mounts. This feature
> allows a read-only view into a read-write filesystem. In the process
> of doing that, it also provides infrastructure for keeping track of
> the number of writers to any given mount. In this version, if there
> are writers on a superblock, the filesystem may not be remounted
> r/o. The same goes for MS_BIND mounts, and writers on a vfsmount.
>
> This has a number of uses. It allows chroots to have parts of
> filesystems writable. It will be useful for containers in the future
> and is intended to replace patches that vserver has had out of the
> tree for several years. It allows security enhancement by making
> sure that parts of your filesystem read-only, when you don't want
> to have entire new filesystems mounted, or when you want atime
> selectively updated.
>
> This set makes no attempt to keep the return codes for these
> r/o bind mounts the same as for a real r/o filesystem or device.
> It would require significantly more code and be quite a bit more
> invasive.
>
> Using this feature requires two steps:
>
> mount --bind /source /dest
> mount -o remount,ro /dest
>
> Signed-off-by: Dave Hansen <[email protected]>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
