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]

Message-ID: <200411240751.iAO7pdMa017788@vaticaan.Holland.Sun.COM>
Date: Wed, 24 Nov 2004 08:51:38 +0100
From: Casper.Dik@....COM
To: James Youngman <bugtraq@...ession.spiral-arm.org>
Cc: srevilak@...akeasy.net, parimiv@...haw.com,
	Martin Buchholz <Martin.Buchholz@....COM>,
	levon@...ementarian.org, bugtraq@...urityfocus.com, bug-findutils@....org
Subject: Re: Changes to the filesystem while find is running - comments?



>I can see that that would be useful but it would fail to comply with
>the POSIX standard, which specifies:
>
>          The find utility shall be able to descend to arbitrary
>          depths in a file hierarchy and shall not fail due to path
>          length limitations (unless a path operand specified by the
>          application exceeds {PATH_MAX} requirements)

But PATH_MAX is limited and the number of file descriptors is perhaps
not.

(On Solaris, PATH_MAX is 1024 so you require at most 512 file
descriptors to keep the stack of directories: 512 is less than the
default hard limit of 65536 file descriptors per process [S9, S8
and before used 1024, still >> 512)

Casper