nfsd4: permit read opens of executable-only files

J. Bruce Fields wrote:

   #define NFSD_MAY_BYPASS_GSS_ON_ROOT 256
   #define NFSD_MAY_NOT_BREAK_LEASE 512
   #define NFSD_MAY_BYPASS_GSS	1024
  +#define NFSD_MAY_READ_IF_EXEC	2048

Not the fault of your patch, but it seems odd, unreadable, and error-prone that these flag bits are defined in terms of base-10 numbers.

From: J. Bruce Fields <bfields@...>

A client that wants to execute a file must be able to read it. Read opens over nfs are therefore implicitly allowed for executable files even when those files are not readable.

NFSv2/v3 get this right by using a passed-in NFSD_MAY_OWNER_OVERRIDE on read requests, but NFSv4 has gotten this wrong ever since dc730e173785e29b297aa605786c94adaffe2544 "nfsd4: fix owner-override on open", when we realized that the file owner shouldn't override permissions on non-reclaim NFSv4 opens.

So we can't use NFSD_MAY_OWNER_OVERRIDE to tell nfsd_permission to allow reads of executable files.

So, do the same thing we do whenever we encounter another weird NFS permission nit: define yet another NFSD_MAY_* flag.

The industry's future standardization on 128-bit processors will be motivated primarily by the need for integers with enough bits for all the NFSD_MAY_* flags.

Reported-by Leonardo Borda <leonardoborda@...>

Cc stable@...

Signed-off-by J. Bruce Fields <bfields@...>

---

Quoted 19 lines · J. Bruce Fields

From: J. Bruce Fields <bfields@...>

A client that wants to execute a file must be able to read it. Read opens over nfs are therefore implicitly allowed for executable files even when those files are not readable.

NFSv2/v3 get this right by using a passed-in NFSD_MAY_OWNER_OVERRIDE on read requests, but NFSv4 has gotten this wrong ever since dc730e173785e29b297aa605786c94adaffe2544 "nfsd4: fix owner-override on open", when we realized that the file owner shouldn't override permissions on non-reclaim NFSv4 opens.

So we can't use NFSD_MAY_OWNER_OVERRIDE to tell nfsd_permission to allow reads of executable files.

So, do the same thing we do whenever we encounter another weird NFS permission nit: define yet another NFSD_MAY_* flag.

Quoted 8 lines

The industry's future standardization on 128-bit processors will be motivated primarily by the need for integers with enough bits for all the NFSD_MAY_* flags.

Reported-by Leonardo Borda <leonardoborda@...>

Cc stable@...

Signed-off-by J. Bruce Fields <bfields@...>

---

<snip>

Bruce,

I've tested this patch against linux-3.0 and it doesn't allow me to execute binaries with permissions of 111.

Here is the BugLink for the Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/833300
My method of reproducing the bug is documented here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/833300/comments/22
This is copied and pasted below:
I can reproduce this failure on natty/oneiric just fine.

I then applied the upstream patch (a043226bc140a2c1dde162246d68a67e5043e6b2), that was identified in the public bug and upstream bug.

After doing this I installed the tools on my laptop:
apt-get install nfs-common nfs-kernel-server

Then I setup of /etc/exports as described in the bug to a directory on my laptop (ext4).
/path/to/dir *(rw,sync,fsid=0,no_subtree_check)

I then had to insert the module and restart the server:
sudo modprobe nfs
sudo service nfs-kernel-server restart

I mounted the directory:
sudo mount -t nfs4 -o proto=tcp,port=2049 localhost:/ /mnt

I created a similar c program and compiled. I put this into the shared folder. I could run it with normal permissions.
I then did 'chmod 111 ./a.out' and then I could not run the program (Permission denied) if I was doing it via the /mnt directory.

arges@arges-virtual-machine:/mnt$ ls -la
total 24
drwxr-xr-x 2 4294967294 4294967294 4096 2011-11-17 10:12 .
drwxr-xr-x 22 root root 4096 2011-11-17 09:57 ..
---x--x--x 1 4294967294 4294967294 8425 2011-11-17 10:12 a.out
-rw-r--r-- 1 4294967294 4294967294 73 2011-11-17 10:12 hello.c
arges@arges-virtual-machine:/mnt$ ./a.out
-bash: ./a.out: Permission denied
arges@arges-virtual-machine:/mnt$ mount -v
/dev/vda1 on / type ext4 (rw,errors=remount-ro,commit=0)
<snip>
nfsd on /proc/fs/nfsd type nfsd (rw)
localhost:/ on /mnt type nfs (rw,vers=4,addr=127.0.0.1,clientaddr=127.0.0.1)

I could run it if I wasn't running it over the nfsv4 share (sanity check):

arges@arges-virtual-machine:/mnt$ cd ~/Test/
arges@arges-virtual-machine:~/Test$ ls -la
total 24
drwxr-xr-x 2 arges arges 4096 2011-11-17 10:12 .
drwxr-xr-x 22 arges arges 4096 2011-11-17 10:10 ..
---x--x--x 1 arges arges 8425 2011-11-17 10:12 a.out
-rw-r--r-- 1 arges arges 73 2011-11-17 10:12 hello.c
arges@arges-virtual-machine:~/Test$ ./a.out
hello binary

Thanks,
--chris j arges

--
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 6 lines

Bruce,

I've tested this patch against linux-3.0 and it doesn't allow me to execute binaries with permissions of 111.

Hm, I see the same permissions error. However, looking at the client-server traffic with wireshark, I see no permissions failures from the server: the read-open of cat succeeds. (Could you check if the same is true in your case?)

So my first inclination is to blame the client.... Does this work with an older client?

--b.

<snip>

Quoted 12 lines

Quoted 6 lines

Bruce,

I've tested this patch against linux-3.0 and it doesn't allow me to execute binaries with permissions of 111.

Hm, I see the same permissions error. However, looking at the client-server traffic with wireshark, I see no permissions failures from the server: the read-open of cat succeeds. (Could you check if the same is true in your case?)

Quoted 4 lines

So my first inclination is to blame the client.... Does this work with an older client?

--b.

Bruce,

Using the above test setup, and trying various clients I see a mismatch:

Using a newer nfs clients (nfs-common 1:1.2.2-4/1:1.2.4-1), I can read a file with 111 permissions, but cannot execute it.
With an older nfs client (nfs-common 1:1.2.0-4 / ubuntu lucid), I can read and execute a file with 111 permissions.