[bugs #11076] Possible symlink race condition

[James Youngman]

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

/**************************************************************************/
[bugs #11076] Latest Modifications:

Changes by: 
                James Youngman <address@hidden>
'Date: 
                Sat 12/04/04 at 13:26 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | Remind                    | Invalid
              Status | Open                      | Closed


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






/**************************************************************************/
[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/04 at 10:35

Category:  find
Severity:  7 - Major
Item Group:  None
Resolution:  Invalid
Privacy:  Public
Assigned to:  jay
Originator Name:  John Levon
Originator Email:  address@hidden
Status:  Closed
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: Sat 12/04/04 at 13:26         By: James Youngman <jay>
This isn't a bug, but it is important that we implement -execdir soon.

-------------------------------------------------------
Date: Sun 11/21/04 at 15:22         By: James Youngman <jay>
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, 
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, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x401682e8) 
= 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
------------------------------------+-----------------------------
ldv                                 | 
levon --AT-- movementarian --DOT-- org | 









For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=11076>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/