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 12:10:45 -0700 [thread overview]
Message-ID: <012801cf9560$29ede7d0$7dc9b770$@mindspring.com> (raw)
In-Reply-To: <CAHQdGtRxORG5kn-9D1Bp7WZ80yF6jGL_M8yT+0KeJ7x-jyVojg@mail.gmail.com>
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).
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.
Has this been resolved differently in a more recent kernel?
Thanks
Frank
> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> owner@vger.kernel.org] On Behalf Of Trond Myklebust
> Sent: Wednesday, June 25, 2014 3:34 PM
> To: Frank Filz
> Cc: Linux NFS Mailing List
> Subject: Re: Execute only permission issue with client
>
> On Wed, Jun 25, 2014 at 6:29 PM, Frank Filz <ffilzlnx@mindspring.com>
> wrote:
> >> On Wed, Jun 25, 2014 at 5:56 PM, Frank Filz <ffilzlnx@mindspring.com>
> >> wrote:
> >> > Back a year ago or so, I ran the following test against Ganesha:
> >> >
> >> > http://www.tuxera.com/community/posix-test-suite/
> >> >
> >> > On NFS v4, one of the issues it tripped over was execute only files.
> >> > Apparently the Linux v4 client doesn't make ACCESS calls in
> >> > conjunction with an open system call, with the result that you can
> >> > open an execute only file (per RFC 3530bis, the server is allowing
> >> > such to allow clients to execute executables).
> >>
> >> That information is outdated. A wireshark dump should show that
> >> recent Linux kernels include an ACCESS operation as part of the
> >> open() COMPOUND and that it uses that information to distinguish
> >> between executable and read access permissions.
> >
> > Oh, cool, do you know when that went in? I'll go look and see if I can find
> it...
> >
>
> It should be a feature of Linux 3.7 (Dec 2012) and newer kernels.
>
> Cheers
> Trond
>
> --
> Trond Myklebust
>
> Linux NFS client maintainer, PrimaryData
>
> trond.myklebust@primarydata.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-07-01 19:10 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 [this message]
2014-07-01 20:13 ` Trond Myklebust
2014-07-01 20:28 ` Frank 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='012801cf9560$29ede7d0$7dc9b770$@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 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.