From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Trond Myklebust'" <trond.myklebust@primarydata.com>
Cc: "'Linux NFS Mailing List'" <linux-nfs@vger.kernel.org>,
"'Linux Kernel mailing list'" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000
Date: Wed, 9 Jul 2014 15:42:22 -0700 [thread overview]
Message-ID: <033801cf9bc7$0d7ee190$287ca4b0$@mindspring.com> (raw)
In-Reply-To: <CAHQdGtSUwScEdUeKT1w+-ynqNz-e1=YvDBtdu_k=_6yndFZSVQ@mail.gmail.com>
> On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz <ffilzlnx@mindspring.com>
> wrote:
> > From: "Frank S. Filz" <ffilzlnx@mindspring.com>
> >
> > The NFS v4 client sends a COMPOUND with an OPEN and an ACCESS.
> >
> > The ACCESS is required to verify an open for read is actually allowed
> > because RFC 3530 indicates OPEN for read only must succeed for an
> > execute only file.
> >
> > The old code expected to have read access if the requested access was
> > O_RDWR.
> >
> > We can expect the OPEN to properly permission check as long as the
> > open is O_WRONLY or O_RDWR.
> >
> > Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
> > ---
> > fs/nfs/nfs4proc.c | 25 ++++++++++++++++++++-----
> > 1 file changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index
> > 4bf3d97..9742054 100644
> > --- a/fs/nfs/nfs4proc.c
> > +++ b/fs/nfs/nfs4proc.c
> > @@ -1966,15 +1966,30 @@ static int nfs4_opendata_access(struct
> rpc_cred *cred,
> > return 0;
> >
> > mask = 0;
> > - /* don't check MAY_WRITE - a newly created file may not have
> > - * write mode bits, but POSIX allows the creating process to write.
> > - * use openflags to check for exec, because fmode won't
> > - * always have FMODE_EXEC set when file open for exec. */
> > + /* Don't trust the permission check on OPEN if open for exec or for
> > + * read only. Since FMODE_EXEC doesn't go across the wire, the server
> > + * has no way to distinguish between an open to read an executable
> file
> > + * and an open to read a readable file. Write access is properly checked
> > + * and permission SHOULD always be granted if the file was created as
> a
> > + * result of this OPEN, no matter what mode the file was created with.
> > + *
> > + * NOTE: If the case of a OPEN CREATE READ-ONLY with a mode that
> does
> > + * not allow read access, this test will produce an incorrect
> > + * EACCES error.
> > + */
> > if (openflags & __FMODE_EXEC) {
> > /* ONLY check for exec rights */
> > mask = MAY_EXEC;
> > - } else if (fmode & FMODE_READ)
> > + } else if (!(fmode & FMODE_WRITE)) {
> > + /* In case the file was execute only, check for read permission
> > + * ONLY if write access was not requested. It is expected that
> > + * an OPEN for write will fail if the file is execute only.
> > + * Note that if the file was newly created, the fmode SHOULD
> > + * include FMODE_WRITE, especially if the file will be created
> > + * with a restrictive mode.
> > + */
> > mask = MAY_READ;
> > + }
>
> This looks wrong. AFAICS it will allow you to open an existing file which has -
> wx permissions (i.e. no read permissions) for O_RDWR. That should not be
> permitted under POSIX rules.
The server permission checks the OPEN, this only affects the subsequent ACCESS.
The server will fail the OPEN with NFS4_ERR_ACCESS if the open is for read/write and the file has write-execute permission.
See the test program I subsequently posted. The program demonstrates that open O_RDWR on a mode=0333 file fails as expected. (Tested on both Ganesha and knfsd).
Frank
next prev parent reply other threads:[~2014-07-09 22:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 21:54 [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000 Frank S. Filz
2014-07-09 22:17 ` Trond Myklebust
2014-07-09 22:42 ` Frank Filz [this message]
2014-07-09 23:06 ` Trond Myklebust
2014-07-09 23:12 ` Trond Myklebust
2014-07-10 4:26 ` Frank Filz
2014-07-10 4:32 ` Trond Myklebust
2014-07-10 5:22 ` Frank Filz
2014-07-10 12:42 ` Trond Myklebust
2014-07-10 14:23 ` Frank Filz
2014-07-11 20:20 ` J. Bruce Fields
2014-07-11 20:46 ` Trond Myklebust
-- strict thread matches above, loose matches on Subject: below --
2014-07-09 21:55 Frank S. Filz
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='033801cf9bc7$0d7ee190$287ca4b0$@mindspring.com' \
--to=ffilzlnx@mindspring.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
/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.