Date: Sat, 8 May 2004 15:59:54 +0200 From: Marc Olzheim <marcolz@stack.nl> To: Tim Robbins <tjr@freebsd.org> Cc: freebsd-current@www.freebsd.org Subject: Re: Unified getcwd() implementation Message-ID: <20040508135954.GA469@stack.nl> In-Reply-To: <20040508070040.GA20138@cat.robbins.dropbear.id.au> 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> <20040508070040.GA20138@cat.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 08, 2004 at 05:00:40PM +1000, Tim Robbins wrote: > 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? Could you please do me the honour of reading the PR's I mentioned ? > 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? standards/44425 mentions why the current implementation is not a bug in the standards point of view. bin/22291, kern/30527, kern/39331 and kern/55993 are about issues we have because of the current implementation. What would be gained from this patch is: - consistency - getcwd() having elevated permission to actually be able to find the real cwd. Now I know that getcwd() shouldn't be used as often as it is used today and that fchdir() can be used instead most of the time, but most software developed on a Linux platform assumes (incorrectly I guess) that getcwd() always succeeds. Marc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040508135954.GA469>