Execute only permission issue with client

Execute only permission issue with client

[Frank Filz]

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

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

Current setup is Fedora 20 with EXT4, running Ganesha 2.1 for NFS server.

Thanks for any insight,

Frank

Re: Execute only permission issue with client

[Trond Myklebust]

Hi Frank

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.

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

[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

-- 
Trond Myklebust

Linux NFS client maintainer, PrimaryData

trond.myklebust@primarydata.com

RE: Execute only permission issue with client

[Frank Filz]

> 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

Re: Execute only permission issue with client

[Trond Myklebust]

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

RE: Execute only permission issue with client

[Frank Filz]

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

Ah, of course we're trying on Fedora 18 with 3.6.10 kernel...

Frank

RE: Execute only permission issue with client

[Frank Filz]

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

Re: Execute only permission issue with client

[Trond Myklebust]

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?

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

-- 
Trond Myklebust

Linux NFS client maintainer, PrimaryData

trond.myklebust@primarydata.com

RE: Execute only permission issue with client

[Frank Filz]

> 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