[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bugs #11076] Possible symlink race condition

From: James Youngman
Subject: [bugs #11076] Possible symlink race condition
Date: Sun, 21 Nov 2004 10:49:45 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Epiphany/1.2.9

This mail is an automated notification from the bugs tracker
 of the project: findutils.

[bugs #11076] Latest Modifications:

Changes by: 
                James Youngman <address@hidden>
                Sun 11/21/2004 at 15:24 (GMT)

            What     | Removed                   | Added
          Resolution | None                      | Remind

[bugs #11076] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11076>
Project: findutils
Submitted by: James Youngman
On: Sun 11/21/2004 at 10:35

Category:  find
Severity:  7 - Major
Item Group:  None
Resolution:  Remind
Privacy:  Public
Assigned to:  jay
Originator Name:  John Levon
Originator Email:  address@hidden
Status:  Open
Release:  4.2.0
Fixed Release:  None

Summary:  Possible symlink race condition

Original Submission:  This space left tempoarily blank; I haven't established 
if we can reproduce this problem with a version of find later than 4.1.7, but 
in any case don't want to send details of an exploit to a publicly archived 
mailing list until after the problem has been solved - ideally, at least.

Follow-up Comments

Date: Sun 11/21/2004 at 15:22       By: James Youngman <jay>
I've figured out how this happens.  The relevant system calls are the 

27681 lstat64("b", {st_dev=makedev(3, 2), st_ino=16677, st_mode=S_IFDIR|0755, 
st_nlink=2, st_uid=1001, st_gid=100, st_blksize=4096, st_blocks=2, 
st_size=1024, st_atime=2004/11/21-14:53:04, st_mtime=2004/11/21-14:53:04, 
st_ctime=2004/11/21-14:53:04}) = 0
27681 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
27681 clone(child_stack=0, 
= 27683
27681 waitpid(27683,  <unfinished ...>
27683 fchdir(3)                         = 0
27683 execve("/bin/touch", ["/bin/touch", "/tmp/racebug/user/b/gotcha"], 
["HZ=10", "TERM=xterm", "SHELL=/bin/bash", "USER=root", 
"PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", 
"PWD=/tmp/racebug", "HOME=/root", "SHLVL=2", "LOGNAME=root", 
"_=/usr/bin/strace"]) = 0

(Under other versions of Unix, the clone system call would be "fork").

The problem is that to implement -exec, "find" changes directory back to the 
directory from which it started (by using fchdir).  The 'touch' command then 
uses the path name /tmp/racebug/user/b/gotcha, but by the time it does that, 
"b" points to /tmp/racebug/root.  Hence the file "/tmp/racebug/root/gotcha" 
gets created, even though find never looked inside /tmp/racebug/root, but only 
in /tmp/racebug/user.

It is this problem that the FreeBSD version of find addresses with "-execdir".  
I have had that on my list of things to do for some time now.  However, I now 
understand more fully why the feature is really necessary.  We can't change the 
behaviour of -exec because the POSIX standard
states that the working directory of the invoked command must be the same as 
the directory which was the working directory when find was invoked.

An analohous problem of course exists with "find ... -print0 | xargs -0 blah 

CC List

CC Address                          | Comment
levon --AT-- movementarian --DOT-- org | 

For detailed info, follow this link:

  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]