Possible permissions bug on NFSv3 kernel client

[Colin Paton <colin.paton@etvinteractive.com>]

Hi,

I have found what I think might be a bug with the kernel NFS v3 client
code. It is however more likely that I am doing something wrong -
perhaps someone might verify my attempted fix!

Google suggests that other people might be having the same problem - but
I couldn't find a fix so had a go myself.

I am trying to export a filesystem as read-only from a server. On my
client machine I boot into an initial filesystem, mount the 'real' root
filesystem over NFS, then pivot_root to it. 

If I mount the root filesystem as NFSv2 (using mount -o nfsvers=2) then
everything works correctly. If I mount as NFSv3 then I run into problems
when trying to write to block/character device files.

Both the client and the server are using kernel 2.4.25, with knfsd on
the server. I case it matters, I am using busybox 1.00-pre8 mount, but
the same thing happens with mount version 2.11n on a Debian system.

Essentially, it does not appear to be possible to write to device files
which are mounted on a read-only NFSv3 filesystem. The problem only
occurs with NFS v3 - Mounting the filesystem as NFSv2 (using mount -o
nfsvers=2) is fine.

To reproduce:

- On a server machine create a character device file on a read-only NFS
exported directory (called 'tty3' in this example)
- Mount the NFS volume on a client machine.
- From the client machine, run 'cat > /mnt/tty3'

The kernel returns EACCES when trying to open the 'tty3' device.

The 'cat > /mnt/tty3' command works properly if the directory is
exported read-write.

Reading from the device file (cat < /mnt/tty3) is fine in all cases.

Doing a trace with ethereal shows that an NFS 'access' RPC is sent to
the server, with the access bitmask set to 'allow MODIFY+EXTEND'. The
server returns that these are not allowed, as the filesystem is mounted
read-only. This causes the EACCES error.

I modified the client kernel code as follows, to make the NFS client
behave differently:

In file: fs/nfs/nfs3proc.c modify nfs3_proc_access(). This calls the
access RPC on the server. I added the following to the code:

            if (S_ISBLK(inode->i_mode) || S_ISCHR(inode->i_mode))
                {
                    // Leave arg.access untouched.
 
                }

...so that the the MODIFY and EXTEND bits aren't set when writing to a
block or character device.

This fix works, yet I believe it might introduce a security problem. I
am not sure where permissions should be properly checked.

The access RPC appears specific to NFS v3. I am not sure how NFS v2 does
permissions checking.

In addition, I am not 100% sure if the problem is at the client end or
the server end - have I just masked the problem rather than actually
fixing it?

Alternatively, of course, there may be some specific reason why NFSv3 is
not recommended for root filesystems - in which case it might be better
to fall back to NFSv2.

Thanks,

Colin