Re: Unified getcwd() implementation

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