All of lore.kernel.org
 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: Wed, 25 Jun 2014 15:29:24 -0700	[thread overview]
Message-ID: <029c01cf90c4$ebae6b60$c30b4220$@mindspring.com> (raw)
In-Reply-To: <CAHQdGtSdQ3keA2UgiAbtWWUMvheWQ8oanpAt_evAY2DSkr+y+Q@mail.gmail.com>

> 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...

> > We tripped over this issue again in some of our testing.
> >
> > One bit that I don't actually understand is how the kernel
> > differentiates between bash (etc) issuing an open system call to load
> > a script and vi trying to browse same script...
> >
> > I had done some testing executing shell scripts and such and saw some
> > inconsistency. Now, trying things, I can't seem to run a bash script
> > that is execute only (local, v3, or v4), but can run a compiled binary
> > that is execute only (local, v3, and v4), so I'm not sure what the deal is...
> 
> The deal is that shell scripts require read permissions because the shell needs
> to be able to open and read them.

Ok, that does actually make sense. I could have sworn I used to be able to run execute only shell scripts from non-root user, but my memory has been known to be faulty.

> [trondmy@leira ~]$ cat >script.sh
> #!/bin/bash
> #
> echo "foo"
> [trondmy@leira ~]$ chmod 0111 script.sh
> [trondmy@leira ~]$ ./script.sh
> /bin/bash: ./script.sh: Permission denied [trondmy@leira ~]$ chmod 0555
> script.sh [trondmy@leira ~]$ ./script.sh foo

Thanks

Frank



  reply	other threads:[~2014-06-25 22: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 [this message]
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

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='029c01cf90c4$ebae6b60$c30b4220$@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.