Possible permissions bug on NFSv3 kernel client
From: Colin Paton
Date: Thu Apr 29 2004 - 06:05:56 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/