Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

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

Subject: Re: Changes to the filesystem while find is running - comments?
Date: Tue, 23 Nov 2004 00:00:41 +0000
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.

<Prev in Thread] Current Thread [Next in Thread>