Who is responsible for the NFS kernel code now? I have a patch for a
bug NFS code, but I don't know who to send it to. (Nobody is listed
in the Maintainers file.)
I'd also appreciate it if someone could verify whether or not they see
this problem and whether my patch fixes it for them. (I've noticed it
with sparc CVS kernels and in 2.1.92 on i386, and I don't see anything
in 2.1.93 to fix it, but I haven't tried a stock 2.1.93 kernel yet.)
The problem is that a setuid root program can't access a file that is
readable by "uid" iff that file resides on an NFS mounted partition.
One way to test for the bug is to make a setuid root version of "cat",
and as a normal user try to cat a NFS mounted file that only that user
can read.
The effect of this bug is that xterm no longer runs if you are:
Using xdm (hence .Xauthority files)
the users home directory is NFS mounted
the NFS mount has root squashed.
There is code to fix this by retrying with the original user id in
net/sunrpc/auth.c, but it checks for NFSERR_PERM, and both Sun's NFS
server and the userspace NFS server that ships with Red Hat 4.2 return
NFSERR_ACCES in these cases.
The patch to fix this is attached to this message.
Steve
dunham@cps.msu.edu
--Multipart_Thu_Apr__9_17:08:49_1998-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="NFS.patch"
Content-Transfer-Encoding: 8bit
--- linux/net/sunrpc/clnt.c.orig Fri Apr 3 09:13:07 1998
+++ linux/net/sunrpc/clnt.c Fri Apr 3 09:13:54 1998
@@ -637,7 +637,8 @@
* The following is an NFS-specific hack to cater for setuid
* processes whose uid is mapped to nobody on the server.
*/
- if (task->tk_client->cl_prog == 100003 && ntohl(*p) == NFSERR_PERM) {
+ if (task->tk_client->cl_prog == 100003 && (ntohl(*p) == NFSERR_PERM
+ || ntohl(*p) == NFSERR_ACCES)) {
if (RPC_IS_SETUID(task) && (task->tk_suid_retry)--) {
dprintk("RPC: %4d retry squashed uid\n", task->tk_pid);
task->tk_flags ^= RPC_CALL_REALUID;
--Multipart_Thu_Apr__9_17:08:49_1998-1--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu