From svdb@inferno.stuiver.net  Sat Jun 15 07:23:14 2002
Return-Path: <svdb@inferno.stuiver.net>
Received: from inferno.stuiver.net (t-indiv8-234.athome.tue.nl [131.155.242.234])
	by hub.freebsd.org (Postfix) with ESMTP id 87A2E37B408
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 15 Jun 2002 07:23:13 -0700 (PDT)
Received: by inferno.stuiver.net (Postfix, from userid 1106)
	id F38FB63; Sat, 15 Jun 2002 16:11:17 +0200 (CEST)
Message-Id: <20020615141117.F38FB63@inferno.stuiver.net>
Date: Sat, 15 Jun 2002 16:11:17 +0200 (CEST)
From: Serge van den Boom <svdb@stack.nl>
Reply-To: Serge van den Boom <svdb@stack.nl>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: namei cache unreliable for __getcwd()
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         39331
>Category:       kern
>Synopsis:       namei cache unreliable for __getcwd()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    dwmalone
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jun 15 07:30:02 PDT 2002
>Closed-Date:    Sat Mar 08 18:29:54 UTC 2008
>Last-Modified:  Sat Mar 08 18:29:54 UTC 2008
>Originator:     Serge van den Boom
>Release:        FreeBSD 4.5-RELEASE i386
>Organization:
M.C.G.V. Stack
>Environment:
System: FreeBSD inferno.stuiver.net 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Sun Mar 17 04:23:07 CET 2002 svdb@inferno.stuiver.net:/usr/src/sys/compile/INFERNO i386

>Description:
The libc function getcwd() calls the kernel function __getcwd() to see if
the current directory is in the namei cache, in which case it can save
itself a lot of work. If not, getcwd() records the path itself by going
back to the root dir by following the '..' links.
The problem is that the information that __getcwd() returns, may be out of
date. A parent dir of the cwd might have been moved, or its permissions may
no longer allow the current user to inspect a dir part.
The result is that getcwd() might sometimes return the incorrect old value,
and sometimes the new, correct value (or error), depending on whether the dir
is in the namei cache. This can lead to unexpected results, as a namei may
leave the cache during the execution of a program, as the 'how-to-repeat'
will show.

>How-To-Repeat:
$ mkdir foo foo/bar foo/bar/{a,b}
$ cd foo/bar
$ chmod ../../foo
$ mv a b /tmp  # A dir on another filesystem
mv: cannot resolve b: b

'a' will be moved, but not 'b'.
So what happened?
For each of the arguments 'a' and 'b', mv calls realpath(), which calls
getcwd(). At the time of the getcwd() call for 'a', the current dir is still
in the namei cache, and __getcwd(), called by getcwd() will return its name.
At the time of the getcwd() call for 'b', the current dir is no longer in
the namei cache, and __getcwd() will fail. getcwd() will try to build the
path itself by following the '..' links, but that fails on the permissions,
so 'b' can't be resolved, and its move fails.

BTW, the reason the move has to be cross-filesystem, is because otherwise
realpath() won't be called by /bin/mv.

>Fix:
Invalidate the namei entry for all subdirs of a dir (and the dir itself)
when its permissions change, or the dir is moved?
Though it's probably not as simple as I might make it look here.

>Release-Note:
>Audit-Trail:

From: Marc Olzheim <marcolz@ilse.nl>
To: Serge van den Boom <svdb@stack.nl>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/39331: namei cache unreliable for __getcwd()
Date: Mon, 24 Jun 2002 14:33:14 +0200

 For this to work, don't forget the 'a-x' with the chmod command.
 
 Marc
Responsible-Changed-From-To: freebsd-bugs->dwmalone 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Sat Jul 13 12:42:27 PDT 2002 
Responsible-Changed-Why:  
I'm interested in these interactions with the name cache. 

I think that the current purging of the name cache associated with 
the moving/removal of a directory is probably unnecessary and the 
real thing to do here may be to check the permessions in the kernel 
code which does real path. I don't think it is possible for the name 
cache to return out of date info though, it may just return info 
which you might not be able to determine purely from userland. 

David. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39331 

From: Marc Olzheim <marcolz@ilse.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc: svdb@stack.nl, dwmalone@FreeBSD.org, marcolz@ilse.net
Subject: Re: kern/39331: namei cache unreliable for __getcwd()
Date: Tue, 4 May 2004 13:45:14 +0200

 I don't know what got fixed, but I cannot reproduce this any more on
 either 4-STABLE or 5-CURRENT.
 
 Marc
State-Changed-From-To: open->closed 
State-Changed-By: rwatson 
State-Changed-When: Sat Mar 8 18:28:23 UTC 2008 
State-Changed-Why:  
Submitter reports that problem is gone; please let us know if it starts 
recurring again by replying to this PR, and we can re-open it.  Thanks! 


http://www.freebsd.org/cgi/query-pr.cgi?pr=39331 
>Unformatted:
