From owner-freebsd-standards@FreeBSD.ORG Wed May 28 11:40:14 2003 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B992637B401 for ; Wed, 28 May 2003 11:40:14 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A24C43F3F for ; Wed, 28 May 2003 11:40:14 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4SIeEUp011506 for ; Wed, 28 May 2003 11:40:14 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4SIeEe1011505; Wed, 28 May 2003 11:40:14 -0700 (PDT) Date: Wed, 28 May 2003 11:40:14 -0700 (PDT) Message-Id: <200305281840.h4SIeEe1011505@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: "Dorr H. Clark" Subject: here's an unnecessary fix (Re: standards/44425: getcwd() succeedseven if current dir has perm 000) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Dorr H. Clark" List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2003 18:40:15 -0000 The following reply was made to PR standards/44425; it has been noted by GNATS. From: "Dorr H. Clark" To: freebsd-gnats-submit@FreeBSD.org, behanna@zbzoom.net, freebsd-standards@FreeBSD.org Cc: Subject: here's an unnecessary fix (Re: standards/44425: getcwd() succeeds even if current dir has perm 000) Date: Wed, 28 May 2003 10:19:30 -0700 The bug 44425 has a straightforward fix, but our research indicates that the fix is not required by the standard. The man page indicates that getcwd() conforms to POSIX.1, which we quote: POSIX.1 section B.5.2.2 : "If a program is operating in a directory where some (grand)parent directory does not permit reading, getcwd() MAY fail, ... " (emphasis added) In otherwords, the behavior described in 44425 is acceptable. We have implemented a fix anyway. In a situation like this, where we're adding a VOP interface into a system call (see below), performance should also be considered. The routine getcwd() is not typically a performance critical component of the file system code, but a clear case exists for keeping the code the way it is instead of applying the enclosed patch. Care also should be taken that there are no unexpected side effects for programs which rely on the standard for normal operation. Note: If you're really interested in file system restricted access for particular users, you might check out the "jail" functionality. What follows is the actual fix. Fix applies to src/sys/kern/vfs_cache.c, please note that our implementation is applied to the 4.7 baseline. --- vfs_cache.c_orig Wed Apr 30 05:43:20 2003 +++ vfs_cache.c Tue May 13 08:45:21 2003 @@ -546,6 +546,7 @@ struct filedesc *fdp; struct namecache *ncp; struct vnode *vp; + struct vattr vattr; /* attributes of vnode */ numcwdcalls++; if (disablecwd) @@ -579,6 +580,22 @@ free(buf, M_TEMP); return (ENOENT); } + + if ((error = VOP_GETATTR(ncp->nc_vp, &vattr, p->p_ucred, p)) != 0) { + free(buf, M_TEMP); + return(error); + } + + + /* check if read or search permissions are denied, if so, then + return an EACCES error and exit. + */ + + if (!(vattr.va_mode & VEXEC) || (!(vattr.va_mode & VREAD))) { + free(buf, M_TEMP); + return(EACCES); + } + if (ncp->nc_dvp != vp->v_dd) { numcwdfail3++; free(buf, M_TEMP); Kalpana Pathak, engineer Dorr H. Clark, advisor COEN 284, Operating Systems Case Study Santa Clara University