bugfindutils - Bugs: bug #11076, Possible symlink race condition

 
 

bug #11076: Possible symlink race condition

Submitted by:  James Youngman <jay>
Submitted on:  Sun 21 Nov 2004 10:35:29 AM UTC  
 
Category:  find Severity:  4 - Important
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  James Youngman <jay>
Originator Name:  John Levon Open/Closed:  Closed
Release:  4.2.0 Fixed Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 04 Dec 2004 01:26:52 PM UTC, comment #2: 

This isn't a bug, but it is important that we implement -execdir soon.

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 21 Nov 2004 03:22:08 PM UTC, comment #1: 

I've figured out how this happens.  The relevant system calls are the following:-

27681 lstat64("b", {st_dev=makedev(3, 2), st_ino=16677, st_mode=S_IFDIR|0755, s\t_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/2\1-14:53:04}) = 0
27681 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
27681 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHL\D, child_tidptr=0x401682e8) = 27683
27681 waitpid(27683,  <unfinished ...>
27683 fchdir(3)                         = 0
27683 execve("/bin/touch", ["/bin/touch", "/tmp/racebug/user/b/gotcha"], ["HZ=1\00", "TERM=xterm", "SHELL=/bin/bash", "USER=root", "PATH=/usr/local/sbin:/usr/l\ocal/"..., "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 ..."

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 21 Nov 2004 10:35:29 AM UTC, 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.

James Youngman <jay>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   patch dependencies.

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

 

 

Follow 7 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-12-04 jay StatusRemind => Invalid
    Open/ClosedOpen => Closed
2004-11-21 ldv Carbon-Copy- => Added ldv
2004-11-21 jay StatusNone => Remind
    Dependencies- => Depends on patch #3504
2004-11-21 jay PrivacyPrivate => Public
2004-11-21 jay Carbon-Copy- => Added levon --AT-- movementarian --DOT-- org

Back to the top


Powered by Savane 3.5