From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Re: [PATCH 09/10] VFS: Remove read-only checks from dentry_permission Date: Wed, 8 Sep 2010 17:47:26 +1000 Message-ID: <20100908174726.21aec19b@notabene> References: <20100906004829.20775.68828.stgit@localhost.localdomain> <20100906005029.20775.70918.stgit@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, haveblue@us.ibm.com, linux-kernel@vger.kernel.org To: Miklos Szeredi Return-path: Received: from cantor2.suse.de ([195.135.220.15]:33033 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756393Ab0IHHri (ORCPT ); Wed, 8 Sep 2010 03:47:38 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 06 Sep 2010 21:10:10 +0200 Miklos Szeredi wrote: > On Mon, 06 Sep 2010, NeilBrown wrote: > > It is not sufficient to depend on the the "filesystem is readonly" > > tests in dentry_permission as it does not check if the vfsmnt is > > readonly. > > All call sites already call mnt_want_write or __mnt_is_readonly which > > includes the test on MS_RDONLY. > > Last time I checked I found some holes (in nfsd IIRC). That was a > long time ago and things may have changed. nfsd looks OK to me. I didn't do an exhaustive audit but couldn't find things that would not still work correctly. > > That check could be replaced with a > > if (IS_RDONLY(inode) && > (S_ISREG(mode) || S_ISDIR(mode) || S_ISLNK(mode))) > BUG(); That wouldn't quite work currently. sys_faccessat checks __mnt_is_readonly *after* the call to dentry_permission, so the above would cause it to BUG. Possibly the __mnt_is_readonly could be checked before dentry_permission. However nfsd_permission is a bit more awkward to fix as sometimes it deliberately wants to ignore read-only-filesystem issues ... but it might still be possible to work around.. > > which would catch these cases but only if the superblock was marked > r/o. Otherwise it's basically impossible to make sure the callers of > the VFS play by the rules. That was one reason I advocated a > path_... interface for the VFS instead of the current dentry based > one, but Al didn't like it. > I guess there comes a point were we just have to document the rules and if someone doesn't play by them - that is a bug... NeilBrown