>>>>> "Dave" == Dave Sainty <dave@dtsp.co.nz> writes:

Dave> This problem is pretty much exclusive to interactions with
Dave> find(1).  Maybe find(1) should be enhanced with a feature to
Dave> chdir() to the directory securely before executing the command,
Dave> and then just pass the unqualified filename to the command.

How do you chdir securely?  Between the time when you first open() an
fd to the directory, and the time when you chdir() to it, there's
another (very small) race condition.  Maybe you need to stat(),
open(), stat() again, and compare the stat buffers.  Then when you
decide to delete, chdir(), stat() again, and compare again.  Would
that get it?  I guess if you compare the device number and the inode
number in each of the stat buffers, you're guaranteed to have the same
file.  The old inode can't have been freed yet, because you have an
open fd to it, so any new file which is moved to its place has to have
a different inode number.

Dave> Because, after all, the problem is not just restricted to
Dave> destructive operations.

Yeah, that's another thing.  I'm not particularly worried about
interactive use, but what if an admin wants to have a nightly chmod or
chown that hits a particular directory?  Currently, we can't do that
without another race condition.  It would be nice to make it possible
for an admin to do this in a secure manner.

Dave> The flag to rm(1) would be useful in some but very few cases,
Dave> and the function could be implemented within rm instead of as a
Dave> system call.  It would just be more expensive that way (rm would
Dave> have to traverse the path itself, stating as it went).  But
Dave> adding new system calls seems..... too much....

I agree with the last statement.

But the preceding one, I don't buy.  rm is vulnerable to the race
condition, too, even when it's just stat()ing every component of a
pathname.  You never know when your quantum of CPU time is going to
end, and another process will be able to do something malicious.

Am I being *too* paranoid?

Chris

-- 
-----------------------------------------------------cjones@math.montana.edu
Chris Jones                                          cjones@honors.montana.edu
           Mad scientist at large                    cjones@nervana.montana.edu
"Is this going to be a stand-up programming session, sir, or another bug hunt?"