> Chris Jones writes:
> 
> > >Number:         7060
> > >Category:       security
> > >Synopsis:       find and rm
> > >Confidential:   no
> > >Severity:       serious
> > >Priority:       medium
> > >Responsible:    security-officer (NetBSD Security Officer)
> > >State:          open
> > >Class:          change-request
> > >Submitter-Id:   net
> > >Arrival-Date:   Sat Feb 27 22:50:00 1999
> > >Last-Modified:
> > >Originator:     Chris Jones
> > >Release:        Feb 23, 1999
> > >Environment:
> > 
> > >Description:
> > NetBSD has had a problem with find and rm in the daily script for a
> > while.  As I understand it, the issue is a race condition:  Find is
> > trying to remove files that match certain criteria, but there is a
> > race condition between the time when it runs stat on a file and when
> > it (or rm) unlinks the file.
> 
> This problem is pretty much exclusive to interactions with find(1).
> Maybe find(1) should be enhanced with a feature to chdir() to the
> directory securely before executing the command, and then just pass
> the unqualified filename to the command.
> 
> Because, after all, the problem is not just restricted to destructive
> operations.
> 
> The flag to rm(1) would be useful in some but very few cases, and the
> function could be implemented within rm instead of as a system call.
> It would just be more expensive that way (rm would have to traverse
> the path itself, stating as it went).  But adding new system calls
> seems..... too much....
> 

Hm, why not add a -rm option to find.  Then there can be no race, since we 
can bypass the inode->filename->inode translation (which is the root cause 
of the hole).