Skip site navigation (1)Skip section navigation (2)
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>