bugtraq - Re: Changes to the filesystem while find is running

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 23 Nov 2004 00:00:41 +0000
From: James Youngman <bugtraq@...ession.spiral-arm.org>
To: Paul Szabo <psz@...hs.usyd.edu.au>
Cc: srevilak@...akeasy.net, parimiv@...haw.com, martin.buchholz@....com,
	levon@...ementarian.org, bugtraq@...urityfocus.com, bug-findutils@....org
Subject: Re: Changes to the filesystem while find is running - comments?

On Tue, Nov 23, 2004 at 07:39:56AM +1100, Paul Szabo wrote:

> What I would like to see implemented (in some messy pseudo-code, starting
> in parent directory):
> 
>   PARENT=stat(".");
>   SUBDIR=stat("subdir");
>   chdir("subdir");
>   DOT=stat(".");
>   if (SUBDIR != DOT) {
>     Print warning message    /*[1]*/
>   }
>   else {
>     Go on with find (recurse)
>   }
>   chdir("..");
>   DOT=stat(".");
>   if (PARENT != DOT) {
>     Print message
>     Exit with fatal error
>   }
> 
> Do not descend into "dodgy" directories, but back out of them; exit fatally
> if you cannot get back to solid ground.
> 
> Is this doable?

Certainly.  In fact it's how GNU findutils is implemented, except for
the fact that the "warning message" is a fatal error in GNU findutils
releases up to and including 4.2.5.  In later versions (we're
currently at 4.2.7 on ftp://alpha.gnu.org/gnu/findutils) a hack was
introduced to try to support a special case which works when we've
traversed an automount mount point on Solaris).

This algorithm is certainly robust, but it will never descend into an
automount directory hierarchy.  Do you think we can do better than
that without opening the door to more exploits?

Regards,
James.