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 12:25:33 -0400 [thread overview]
Message-ID: <20100422162533.GH5926@fieldses.org> (raw)
In-Reply-To: <20100422101042.226f71d6-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
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?
--b.
>
> Note that I haven't actually seen this cause a problem. I was just looking
> at the code trying to figure out a different EXCLUSIVE open related issue,
> and this looked wrong.
>
> NeilBrown
>
>
> Signed-off-by: NeilBrown <neilb@suse.de>
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 6dd5f19..ec40b36 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1451,8 +1451,11 @@ nfsd_create_v3(struct svc_rqst *rqstp, struct svc_fh *fhp,
> case NFS3_CREATE_EXCLUSIVE:
> if ( dchild->d_inode->i_mtime.tv_sec == v_mtime
> && dchild->d_inode->i_atime.tv_sec == v_atime
> - && dchild->d_inode->i_size == 0 )
> + && dchild->d_inode->i_size == 0 ) {
> + if (created)
> + *created = 1;
> break;
> + }
> /* fallthru */
> case NFS3_CREATE_GUARDED:
> err = nfserr_exist;
next parent reply other threads:[~2010-04-22 16:25 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 ` J.Bruce Fields [this message]
2010-04-22 21:16 ` [PATCH] - avoid permission checks on EXCLUSIVE_CREATE replay Neil Brown
[not found] ` <20100423071631.27ff3a5a-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2010-04-22 21:18 ` J.Bruce Fields
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=20100422162533.GH5926@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).