From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 00/26] Mount writer count and read-only bind mounts Date: Sat, 23 Jun 2007 09:52:46 -0700 Message-ID: <20070623095246.a9061585.akpm@linux-foundation.org> References: <20070622200303.82D9CC3A@kernel> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org, viro@ftp.linux.org.uk, haveblue@us.ibm.com To: Dave Hansen Return-path: Received: from smtp2.linux-foundation.org ([207.189.120.14]:41385 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761291AbXFWQxq (ORCPT ); Sat, 23 Jun 2007 12:53:46 -0400 In-Reply-To: <20070622200303.82D9CC3A@kernel> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > On Fri, 22 Jun 2007 13:03:03 -0700 Dave Hansen 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?