Date: Thu, 21 Nov 2002 12:50:02 -0800 (PST) From: "Peter Edwards" <pmedwards@eircom.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/44336: NFSv3 client broken - security problem with attribute caching Message-ID: <200211212050.gALKo2JB030894@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/44336; it has been noted by GNATS.
From: "Peter Edwards" <pmedwards@eircom.net>
To: freebsd-gnats-submit@FreeBSD.org, mlelstv@dev.de.cw.net
Cc:
Subject: Re: kern/44336: NFSv3 client broken - security problem with attribute caching
Date: Thu, 21 Nov 2002 20:38:51 +0000
Interesting. My reading of the code produces the following understanding:
Basically, there's a separate "access" cache, and an "attributes" cache. A
"setattr" command doesn't clear the "access" cache. (Actually, I don't know
how it flushes the "attribute" cache either, but I haven't studied the code
enough to say that it doesn't.)
I think the intention here is to keep the notion of accessibilty removed
from the notions of attributes and ownership: eg, when user IDs are remapped
by the server, the client can't assume it can access a file based on process
user Id. It's also more useful for servers that don't have a UFS-style
filesystem underlying the server. A quick scan of RFC1813 seems to confirm
this.
My naiive fix (reproduced below) stops this problem happening on my box:
It's reasonable to expect that modifying the mode on a file will affect
its accessibility (although I suppose its not neccessarily definite). The
patch merely invalidates the access cache in the node, forcing the server
to refetch if it needs it.
E&OE. Don't take these as words of wisdom: I'm not an NFS hacker by any
stretch of the imagination: I was just curious enough to look at the source
and partially understand what was going on.
BTW: I don't know if this is a major security concern, generally. If you had
the file open and someone changes the mode, it doesn't prevent you from
accessing it via the open handle (which I assume is similar to how the NFS
server is getting away with it). And the updates will always be reasonably
timely. It certainly breaks POLA in this case though.
Index: nfs_vnops.c
===================================================================
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/nfs/Attic/nfs_vnops.c,v
retrieving revision 1.150.2.5
diff -u -r1.150.2.5 nfs_vnops.c
--- nfs_vnops.c 20 Dec 2001 19:56:28 -0000 1.150.2.5
+++ nfs_vnops.c 21 Nov 2002 20:36:57 -0000
@@ -743,6 +743,13 @@
(error = nfs_vinvalbuf(vp, V_SAVE, ap->a_cred,
ap->a_p, 1)) == EINTR)
return (error);
+
+ /*
+ * It's likely that changing the file's mode will affect it's
+ * accessibilty: invalidate access cache
+ */
+ if (vap->va_mode != (mode_t)VNOVAL)
+ np->n_modestamp = 0;
error = nfs_setattrrpc(vp, vap, ap->a_cred, ap->a_p);
if (error && vap->va_size != VNOVAL) {
np->n_size = np->n_vattr.va_size = tsize;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211212050.gALKo2JB030894>