> On Fri, 22 Jun 2007 13:03:03 -0700 Dave Hansen <[EMAIL PROTECTED]> wrote: > Why do we need r/o 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. > > This has a number of uses. It allows chroots to have parts of > filesystems writable. It will be useful for containers in the future > because users may have root inside a container, but should not > be allowed to write to somefilesystems. This also replaces > 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 (such as when you don't trust your > FTP server), when you don't want to have entire new filesystems > mounted, or when you want atime selectively updated. > I've been using the following script to test that the feature is > working as desired. It takes a directory and makes a regular > bind and a r/o bind mount of it. It then performs some normal > filesystem operations on the three directories, including ones > that are expected to fail, like creating a file on the r/o > mount.
Doesn't selinux do some of this? My overall reaction: owch. There's a ton of tricksy code here and great potential for us to accidentally break it in the future by forgetting a mnt_may_write() as the kernel evolves. And then there's the added complexity and the added runtime overhead. Balance that against some pretty obscure-looking benefits and I'm struggling to see how a merge is justifiable? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
