Execute only permission issue with client
Subsystems (2)
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
Hi Frank
Quoted 9 lines · 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).
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.
Quoted 11 lines
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
Signature · 5 lines
Trond Myklebust Linux NFS client maintainer, PrimaryData [email protected]
Quoted 12 lines
Quoted 9 lines · 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).
Quoted 4 lines
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...
Quoted 6 lines
Quoted 6 lines
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...
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
[trondmy@leira ~]$ cat >script.sh
#!/bin/bash
#
echo "foo"
[trondmy@leira ~]$ chmod 0111script.sh
[trondmy@leira ~]$ ./script.sh/bin/bash: ./script.sh: Permission denied [trondmy@leira ~]$ chmod 0555script.sh[trondmy@leira ~]$ ./script.sh foo
Thanks
Frank
Quoted 12 lines · Frank Filz
Quoted 12 lines
Quoted 9 lines · 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).
Quoted 7 lines
Quoted 4 lines
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
Signature · 5 lines
Trond Myklebust Linux NFS client maintainer, PrimaryData [email protected]
Quoted 19 lines
Quoted 17 lines · Frank Filz
Quoted 16 lines
Quoted 9 lines · 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).
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.
Quoted 5 lines
Quoted 1 line
Oh, cool, do you know when that went in? I'll go look and see if I can find
it...
Quoted 1 line
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
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
Quoted 46 lines
-----Original Message-----
From: [email protected] [mailto:linux-nfs- [email protected]] 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 clientQuoted 12 lines · Frank Filz
Quoted 12 lines
Quoted 9 lines · 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).
Quoted 6 lines
Quoted 4 lines
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...
Quoted 1 line
It should be a feature of Linux 3.7 (Dec 2012) and newer kernels.
Cheers
Trond--
Trond MyklebustLinux NFS client maintainer, PrimaryData
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · 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).
The test fails, or the open() fails?
Quoted 5 lines
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.
Signature · 5 lines
Trond Myklebust Linux NFS client maintainer, PrimaryData [email protected]
Quoted 11 lines · Frank Filz
Quoted 7 lines
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).
Quoted 14 lines
Quoted 1 line
When I look at a wireshark trace, I see that the sequence of ops in the
COMPOUND is:
Quoted 4 lines
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/fooalready exists and that file's ACL/mode is compatible with the requestedO_RDWRaccess pattern. Theopen()should also succeed if a file/mnt/foodoes not exist, and your process has valid file create permissions for the directory /mnt (it will create a file/mnt/foowith the mode bits set to 0).
Quoted 2 lines
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
Quoted 6 lines
--
Trond MyklebustLinux NFS client maintainer, PrimaryData