From: Neil Brown <neilb@suse.de>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, haveblue@us.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 09/10] VFS: Remove read-only checks from dentry_permission
Date: Wed, 8 Sep 2010 17:47:26 +1000 [thread overview]
Message-ID: <20100908174726.21aec19b@notabene> (raw)
In-Reply-To: <E1Osh50-0005s0-V7@pomaz-ex.szeredi.hu>
On Mon, 06 Sep 2010 21:10:10 +0200
Miklos Szeredi <miklos@szeredi.hu> 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
next prev parent reply other threads:[~2010-09-08 7:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-06 0:50 [PATCH 00/10] Assorted fixes/enhancements for overlayfs NeilBrown
2010-09-06 0:50 ` [PATCH 02/10] ovl: minimal remount support NeilBrown
2010-09-06 0:50 ` [PATCH 03/10] ovl: use correct seek function for directories NeilBrown
2010-09-06 0:50 ` [PATCH 01/10] ovl: small optimisation for ovl_lookup NeilBrown
2010-09-06 16:57 ` Miklos Szeredi
2010-09-06 0:50 ` [PATCH 08/10] VFS: tiny optimisation in open_other handling NeilBrown
2010-09-06 0:50 ` [PATCH 04/10] ovl: initialise is_real before use NeilBrown
2010-09-06 0:50 ` [PATCH 10/10] ovl: Assorted updates to Documentation/filesystems/overlayfs.txt NeilBrown
2010-09-06 0:50 ` [PATCH 05/10] ovl: make sure fsync is never called on the lower filesystem NeilBrown
2010-09-06 17:16 ` Miklos Szeredi
2010-09-06 0:50 ` [PATCH 06/10] ovl: rename ovl_fill_cache to ovl_dir_read NeilBrown
2010-09-06 0:50 ` [PATCH 07/10] ovl: add initial revalidate support NeilBrown
2010-09-16 14:47 ` Miklos Szeredi
2010-09-21 2:40 ` Neil Brown
2010-09-06 0:50 ` [PATCH 09/10] VFS: Remove read-only checks from dentry_permission NeilBrown
2010-09-06 19:10 ` Miklos Szeredi
2010-09-08 7:47 ` Neil Brown [this message]
2010-09-08 8:58 ` Miklos Szeredi
2010-09-07 15:58 ` Dave Hansen
2010-09-06 19:23 ` [PATCH 00/10] Assorted fixes/enhancements for overlayfs Miklos Szeredi
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=20100908174726.21aec19b@notabene \
--to=neilb@suse.de \
--cc=haveblue@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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;
as well as URLs for NNTP newsgroup(s).