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 01/10] ovl: small optimisation for ovl_lookup NeilBrown
2010-09-06 16:57 ` Miklos Szeredi
2010-09-06 0:50 ` [PATCH 03/10] ovl: use correct seek function for directories NeilBrown
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 0:50 ` [PATCH 08/10] VFS: tiny optimisation in open_other handling 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 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 06/10] ovl: rename ovl_fill_cache to ovl_dir_read 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 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.