Re: Changes to the filesystem while find is running - comments?

[Troy]

James,

Would it be possible to replace the sanity check for inode number with a
sanity check for cwd and directory name? After all, if the directory is 
moved (renamed or given another parent directory) while find is running, 
then the CWD will have changed. On the other hand, if stat'ing or chdir'ing 
the directory has caused automount to mount a new filesystem on it, the 
CWD will not have changed. This would seem to be a fix.

What do you think?


Troy
 


> 
> Hello,
> 
> GNU find does a sanity check before and after calling chdir().  It
> stats the directory it's about to move into, and stats "." after
> chdir() succeeds.  It then compares the device numbers and inode
> numbers returned by he two stat() calls.  This is done in a function
> called wd_sanity_check().  If these are different, find prints an
> error and exits fatally (in versions up to and including GNU findutils
> 4.2.5.
> 
> The intent here is to detect the situation when someone is moving
> directories about while find is running.  This could be done with
> malicious intent.  The thinking behind this is that (for example)
> there is a risk that find be persuaded to search a part of the
> filesystem which it hadn't planned to (e.g. find /foo -depth -delete).
> 
> If you are running an automounter, it will often mount a filesystem
> when triggered by the fact that a process chdir()s into a mount point.
> This will obviously trigger a failure in the check that
> wd_sanity_check() performs.  Hence for many versions of findutils,
> find will not be able to search a directory hierarchy containing an
> automountd mount point.   That's obviously undesirable.
> 
> I have recently started trying to figure out a way to solve this
> problem without entirely disabling wd_sanity_check().   
> 
> As of findutils 4.2.6/4.2.7, find will read /etc/mtab (/etc/mnttab, or
> whatever it is called on the current system) to determine if the
> directory it has just moved into has recently been either mounted or
> unmounted.  It does this by reading the mount table at startup and
> again when wd_sanity_check() detects a problem (if the filesystem
> appears in one list but not the other, it has either been mounted or
> unmounted).  If ...
> 
> 1. the relevant directory has recently been mounted or unmounted
> AND
> 2. find is travelling down the directory hierarchy, not up
> 
> ... then wd_sanity_check() allows the program to continue but prints a
> warning.  Otherwise, it will exit fatally as before.  The rationale
> behind being sensitive to the direction of the chdir() is that
> chdir("..") shouldn't cause a filesystem to become mounted and
> although the automountd might time a filesystem out and unmount it,
> this only happens after a period of inactivity, and find will have
> just been using this particular filesystem.  The check in
> wd_sanity_check() doesn't pay attention to the actual type of the
> filesystem (though it does report the type in the error message).
> 
> I have run into a problem as of findutils-4.2.7.  This is simply that
> there seem to be cases where automountd on Solaris works by exchanging
> one mounted filesystem for another.  I could support/allow this
> behaviour by noticing that the device number for the filesystem has
> changed and allow the wd_sanity_check() test to succeed, but then the
> effect of this change is that almost any combination of changes to the
> filesystem device number is permitted.  Hence my question is :-
> 
>     Is it worthwhile at all to perform this "sanity check" or is it of 
>     insufficient benefit?
> 
> If there is some benefit in making a test of this type, what scenarios
> should find watch out for?  What tests are useful and practical to
> help find determine if someone is trying to exploit or mislead it?
> 
> I'm not considering here cases where the find command line is
> specified by an untrusted data source - for the purposes of this
> discussion the source of untrusted data is the directory hierarchy
> that find is traversing.
> 
> I'd be grateful for your thoughts.
> 
> Regards,
> James.
>