[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <200411230138.iAN1cqk309940@milan.maths.usyd.edu.au>
Date: Tue, 23 Nov 2004 12:38:52 +1100 (EST)
From: psz@...hs.usyd.edu.au (Paul Szabo)
To: bugtraq@...ession.spiral-arm.org
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?
James,
>> 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
>> }
>
> 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).
So, you already do the "where did I get back to after chdir(..)" check?
> 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?
Hmm... It would not descend into just-now-changed automounts (and it may
not be able to get back out of them), but it should be able to traverse
reasonably long-lived mounts.
Cheers,
Paul Szabo - psz@...hs.usyd.edu.au http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics University of Sydney 2006 Australia
Powered by blists - more mailing lists