From: "J.Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] - avoid permission checks on EXCLUSIVE_CREATE replay
Date: Thu, 22 Apr 2010 17:18:01 -0400 [thread overview]
Message-ID: <20100422211801.GF10302@fieldses.org> (raw)
In-Reply-To: <20100423071631.27ff3a5a-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
On Fri, Apr 23, 2010 at 07:16:31AM +1000, Neil Brown wrote:
> On Thu, 22 Apr 2010 12:25:33 -0400
> "J.Bruce Fields" <bfields@fieldses.org> wrote:
>
> > On Thu, Apr 22, 2010 at 10:10:42AM +1000, Neil Brown wrote:
> > >
> > > With NFSv4, if we create a file then open it we explicit avoid checking the
> > > permissions on the file during the open because the fact that we created it
> > > ensures we should be allow to open it (the create and the open should appear
> > > to be a single operation).
> > >
> > > However if the reply to an EXCLUSIVE create gets lots and the client resends
> > > the create, the current code will perform the permission check - because it
> > > doesn't realise that it did the open already..
> > >
> > > This patch should fix this.
> >
> > Thanks, but: hm, does this leave a loophole for a clever attacker?
> > They'll still have to get past the initial
> >
> > fh_verify(rqstp, fhp, S_IFDIR, NFSD_MAY_CREATE)
> >
> > but that just checks the parent directory; if the existing file is
> > actually owned by someone else, do we allow an open that we shouldn't?
> >
> > Maybe when "created" is set we should keep the permission check but add
> > NFSD_ALLOW_OWNER_OVERRIDE?
> >
>
> I think that is possibly a good idea. However......
>
> commit 81ac95c5569d7a60ab5db6c1ccec56c12b3ebcb5
> Author: J. Bruce Fields <bfields@fieldses.org>
> Date: Wed Nov 8 17:44:40 2006 -0800
>
> [PATCH] nfsd4: fix open-create permissions
>
> In the case where an open creates the file, we shouldn't be rechecking
> permissions to open the file; the open succeeds regardless of what the new
> file's mode bits say.
>
> This patch fixes the problem, but only by introducing yet another parameter
> to nfsd_create_v3. This is ugly. This will be fixed by later patches.
>
>
> I wouldn't want to get in the way of these 'later patches' that might be
> going to remove the 'created' flag from nfsd_create_v3 :-)
Har. I was optimistic.
That code *is* really hairy. I'll take another look.
--b.
next prev parent reply other threads:[~2010-04-22 21:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100422101042.226f71d6@notabene.brown>
[not found] ` <20100422101042.226f71d6-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-04-22 16:25 ` [PATCH] - avoid permission checks on EXCLUSIVE_CREATE replay J.Bruce Fields
2010-04-22 21:16 ` Neil Brown
[not found] ` <20100423071631.27ff3a5a-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-04-22 21:18 ` J.Bruce Fields [this message]
2012-12-07 22:50 ` J.Bruce Fields
2012-12-09 23:37 ` NeilBrown
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=20100422211801.GF10302@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/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).