From owner-freebsd-bugs Thu Nov 21 12:50: 5 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63F1537B401 for ; Thu, 21 Nov 2002 12:50:03 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F15C643E42 for ; Thu, 21 Nov 2002 12:50:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id gALKo2x3030896 for ; Thu, 21 Nov 2002 12:50:02 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id gALKo2JB030894; Thu, 21 Nov 2002 12:50:02 -0800 (PST) Date: Thu, 21 Nov 2002 12:50:02 -0800 (PST) Message-Id: <200211212050.gALKo2JB030894@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Peter Edwards" Subject: Re: kern/44336: NFSv3 client broken - security problem with attribute caching Reply-To: "Peter Edwards" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/44336; it has been noted by GNATS. From: "Peter Edwards" 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