Date: Sat, 8 May 2004 17:00:40 +1000 From: Tim Robbins <tjr@freebsd.org> To: Bruce M Simpson <bms@spc.org> Cc: freebsd-current@www.freebsd.org Subject: Re: Unified getcwd() implementation Message-ID: <20040508070040.GA20138@cat.robbins.dropbear.id.au> In-Reply-To: <20040508044207.GB38736@empiric.dek.spc.org> References: <20040507092235.GA61837@stack.nl> <20040507100119.GA15782@cat.robbins.dropbear.id.au> <20040507235556.GB37035@empiric.dek.spc.org> <20040508010228.GA18935@cat.robbins.dropbear.id.au> <20040508012357.GA37547@empiric.dek.spc.org> <20040508030258.GA19512@cat.robbins.dropbear.id.au> <20040508044207.GB38736@empiric.dek.spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 08, 2004 at 05:42:07AM +0100, Bruce M Simpson wrote: > On Sat, May 08, 2004 at 01:02:58PM +1000, Tim Robbins wrote: > > I don't see how it differs from what we already do in userland. > > Quite a bit different, actually. I refer the honorable gentleman to > Marc Olzheim's message with the Message-ID: <20040507105355.GA93808@stack.nl>. The message that you refer to says: "Because getcwd() is a function that might or might not return EACCESS in the current implementation, depending on whether the current path is in the cache or not. If in /a/b/c/ directory b is unreadable for a user, /a/b/c is returned by getcwd() as long as it is in the cache (kernel), if not, the libc getcwd tries to resolve it, but fails." This is obviously a bug in the current implementation -- it should use VOP_ACCESS to check that the calling process has access to the vnodes of the current directory and its parents. How does the patch in question address this issue? Both the current implementation and the proposed new implementation try to find the pathname use the namecache without authorization checks, then if that fails, go on to read the directories, but this time with authorization checks. What is the difference? Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040508070040.GA20138>