From: linuxram@us.ibm.com (Ram Pai)
To: Dave Hansen <haveblue@us.ibm.com>
Cc: viro@ftp.linux.org.uk, serue@us.ibm.com,
linux-kernel@vger.kernel.org, linuxram@us.ibm.com
Subject: Re: [RFC][PATCH 00/27] Mount writer count and read-only bind mounts (v4)
Date: Thu, 13 Jul 2006 00:04:31 -0700 [thread overview]
Message-ID: <20060713070431.GA12953@RAM> (raw)
In-Reply-To: <20060712181709.5C1A4353@localhost.localdomain>
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 <haveblue@us.ibm.com>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2006-07-13 7:07 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-12 18:17 [RFC][PATCH 00/27] Mount writer count and read-only bind mounts (v4) Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 01/27] prepare for write access checks: collapse if() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 02/27] r/o bind mount prepwork: move open_namei()'s vfs_create() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 04/27] reintroduce list of vfsmounts over superblock Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 03/27] unlink: monitor i_nlink Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 05/27] Add vfsmount writer count Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 06/27] record when sb_writer_count elevated for inode Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 07/27] kill open files traverse on remount ro Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 08/27] increment sb writer count when nlink hits zero Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 09/27] elevate writer count for chown and friends Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 10/27] elevate mnt writers for callers of vfs_mkdir() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 11/27] elevate write count during entire ncp_ioctl() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 12/27] sys_symlinkat() elevate write count around vfs_symlink() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 13/27] elevate mount count for extended attributes Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 14/27] sys_linkat(): elevate write count around vfs_link() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 15/27] mount_is_safe(): add comment Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 16/27] unix_find_other() elevate write count for touch_atime() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 17/27] elevate write count over calls to vfs_rename() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 18/27] tricky: elevate write count files are open()ed Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 19/27] elevate writer count for do_sys_truncate() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 21/27] elevate write count for do_sys_utime() and touch_atime() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 20/27] elevate write count for do_utimes() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 22/27] sys_mknodat(): elevate write count for vfs_mknod/create() Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 23/27] elevate mnt writers for vfs_unlink() callers Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 24/27] do_rmdir(): elevate write count Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 25/27] elevate writer count for custom 'struct file' Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 26/27] Originally from: Herbert Poetzl <herbert@13thfloor.at> Dave Hansen
2006-07-12 18:17 ` [RFC][PATCH 27/27] honor r/w changes at do_remount() time Dave Hansen
2006-07-13 7:04 ` Ram Pai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060713070431.GA12953@RAM \
--to=linuxram@us.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serue@us.ibm.com \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox