Re: Unified getcwd() implementation

From: Tim Robbins <tjr_at_freebsd.org>
Date: Sun, 9 May 2004 01:14:12 +1000
On Sat, May 08, 2004 at 03:59:54PM +0200, Marc Olzheim wrote:
> 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.

You have already mentioned these, and I have read them.

> 
> What would be gained from this patch is:
> - consistency

The only differences I can see between the current implementation and the
proposed new implementation are: (a) if not all the name components are in
the namecache, the (possibly stale) entries can be used instead of
those obtained through readdir, and (b) getcwd() works on unionfs again
because it compares vnode pointers instead of device/inode pairs.
Am I missing something?

> - getcwd() having elevated permission to actually be able to find the
>   real cwd.

>From what I can see, it still uses the caller's credentials in calls
to VOP_GETATTR(), VOP_LOOKUP() and VOP_READDIR().


Tim
Received on Sat May 08 2004 - 06:15:17 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:53 UTC