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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <000101c4d2b6$31fdbd50$86c8a8c0@MervaSBS2003.local>
Date: Thu, 25 Nov 2004 07:15:43 +0100
From: <Casper.Dik@....COM>
To: <kbo@....tiscali.de>
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