Linux NFS development
 help / color / mirror / Atom feed
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Trond Myklebust'" <trond.myklebust@primarydata.com>
Cc: "'Linux NFS Mailing List'" <linux-nfs@vger.kernel.org>
Subject: RE: Execute only permission issue with client
Date: Tue, 1 Jul 2014 13:28:55 -0700	[thread overview]
Message-ID: <013101cf956b$1e6b9500$5b42bf00$@mindspring.com> (raw)
In-Reply-To: <CAHQdGtSMEGvsKt-k+LJM9w-PNu6dTOQABocX-u=10Uyj1tehwg@mail.gmail.com>

> On Tue, Jul 1, 2014 at 3:10 PM, Frank Filz <ffilzlnx@mindspring.com> wrote:
> > Ok, got another question related...
> >
> > I am running a test that does make the following system call:
> >
> > open("/mnt/foo", O_CREAT | O_TRUNC | O_RDWR, 0);
> >
> > This fails (at least when run from my Fedora 20 client, against either
> Ganesha OR knfsd).
> 
> The test fails, or the open() fails?

The open fails (with EACCESS).

> > When I look at a wireshark trace, I see that the sequence of ops in the
> COMPOUND is:
> >
> > OPEN, ACCESS
> >
> > I would expect the ACCESS to fail since the created file has mode 000.
> 
> According to POSIX, the above open() system call should succeed if a file
> /mnt/foo already exists and that file's ACL/mode is compatible with the
> requested O_RDWR access pattern. The open() should also succeed if a file
> /mnt/foo does not exist, and your process has valid file create permissions
> for the directory /mnt (it will create a file /mnt/foo with the mode bits set to
> 0).
> 
> In both cases, the result should be a valid file descriptor that can be used for
> reading and writing.

Right, and I see that the ACCESS MUST be called AFTER the OPEN (to capture the situation where the file already exists), however, if the file did not exist, the ACCESS fails.

Hmm, the poor client actually has no way to handle this...

And we need the ACCESS call in case the file already existed and was execute only.

I'm not sure the protocol actually allows a proper implementation of this variant of the open system call...

Life would have been a bit easier if the protocol had an ACCESS4_EXECUTE flag for OPEN... But there might still be issues of how to accomplish the permission check and create atomically...

Frank

> --
> Trond Myklebust
> 
> Linux NFS client maintainer, PrimaryData
> 
> trond.myklebust@primarydata.com


      reply	other threads:[~2014-07-01 20:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25 21:56 Execute only permission issue with client Frank Filz
2014-06-25 22:21 ` Trond Myklebust
2014-06-25 22:29   ` Frank Filz
2014-06-25 22:34     ` Trond Myklebust
2014-06-25 22:41       ` Frank Filz
2014-07-01 19:10       ` Frank Filz
2014-07-01 20:13         ` Trond Myklebust
2014-07-01 20:28           ` Frank Filz [this message]

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='013101cf956b$1e6b9500$5b42bf00$@mindspring.com' \
    --to=ffilzlnx@mindspring.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox