From owner-freebsd-bugs Sat Feb 1 16:20:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18684 for bugs-outgoing; Sat, 1 Feb 1997 16:20:08 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18670; Sat, 1 Feb 1997 16:20:04 -0800 (PST) Resent-Date: Sat, 1 Feb 1997 16:20:04 -0800 (PST) Resent-Message-Id: <199702020020.QAA18670@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, dwmalone@maths.tcd.ie Received: from salmon.maths.tcd.ie (mmdf@salmon.maths.tcd.ie [134.226.81.11]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA18596; Sat, 1 Feb 1997 16:19:22 -0800 (PST) Received: from graves.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id aa22105; 2 Feb 97 0:19 +0000 Message-Id: <9702020019.aa00900@graves.maths.tcd.ie> Date: Sun, 2 Feb 97 0:19:13 +0000 From: dwmalone@maths.tcd.ie Reply-To: dwmalone@maths.tcd.ie To: FreeBSD-gnats-submit@freebsd.org Cc: dwmalone@maths.tcd.ie, iedowse@maths.tcd.ie, mpp@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/2635: NFS cache and access permissions. Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 2635 >Category: kern >Synopsis: NFS cache doesn't check execute permission on directories >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Feb 1 16:20:01 PST 1997 >Last-Modified: >Originator: David Malone >Organization: School of Maths, Trinity College, Dublin. >Release: FreeBSD 2.2-GAMMA i386 >Environment: FreeBSD-2.2-GAMMA and FreeBSD-stable NFS clients. Probably current too ( based on a quick look at nfs_vnops.c ). >Description: This bug is similar, but NOT the same as kern/876. Suppose a user has permission to read the file /a/b/c, but should not be able to because the directory /a/b is not executable by them. If /a/b is in the NFS client cache it will allow them to read the file, as the cache code does't check for executability of the containing directory. This came to note because the web server was stating a file as root, and then serving it as nobody, when it should not have been able to. If you have NFS mounted home directories it means users stand a good chance of being able to view one anothers files. For some reason lstat'ing a file in the directory in question seems to invalidate the cache. >How-To-Repeat: [As nobody] 18:37:salmon 29% cat ~dwmalone/.mail/incoming_mail cat: /u2/system/dwmalone/.mail/incoming_mail: Permission denied [As dwmalone] salmon 7% ls -ld incoming_mail . -rw-r--r-- 1 dwmalone system 32888 Feb 1 17:56 incoming_mail drws------ 18 dwmalone system 1024 Feb 1 16:11 . salmon 8% cat incoming_mail blah blah blah [As nobody] 19:38:salmon 33% cat ~dwmalone/.mail/incoming_mail blah blah blah [As dwmalone] salmon 9% perl -e 'lstat("incoming_mail");' [As nobody] 19:38:salmon 33% cat ~dwmalone/.mail/incoming_mail cat: /u2/system/dwmalone/.mail/incoming_mail: Permission denied >Fix: In sys/nfs/nfs_vops.c we found that nfs_lookup does not check for executability of a directory. Presumably this is OK if you are not looking in the NFS attribute cache, as the NFS server should do the check for you. We made the following patch, following sys/ufs/ufs/ufs_lookup.c as a guideline. It seems to work ( fingers crossed ), and only does the check if we are looking in the cache. On the other hand, there may be locking or stuff to be done we don't know about. *** /FreeBSD/FreeBSD-2.2/src/sys/nfs/nfs_vnops.c Wed Jan 8 23:50:18 1997 --- ./nfs_vnops.c Sat Feb 1 23:10:53 1997 *************** *** 840,845 **** --- 840,849 ---- if ((error = cache_lookup(dvp, vpp, cnp)) && error != ENOENT) { struct vattr vattr; int vpid; + + if (error=VOP_ACCESS(dvp,VEXEC,cnp->cn_cred,cnp->cn_proc)) { + return (error); + } newvp = *vpp; vpid = newvp->v_id; >Audit-Trail: >Unformatted: