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
| ||
|
Message-ID: <200411241929.iAOJT4Ma018891@vaticaan.Holland.Sun.COM> Date: Wed, 24 Nov 2004 20:29:04 +0100 From: Casper.Dik@....com To: "Doug Moen" <doug.moen@...ecoat.com> Cc: srevilak@...akeasy.net, James Youngman <bugtraq@...ession.spiral-arm.org>, 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? >Modern kernels seem to have arbitrary fixed limits for just about >everything. There's generally an arbitrary limit on buffers to do I/O with the kernel with as the kernel typically needs to allocate a buffer to compute results in before it does a copyout (think readdir() and others) >My understanding is that this is sound engineering practice. It protects >the system against rogue processes, and contributes to security and stability. Quite. For pathname,s the kernel also needs to know how big a buffer to allocate before reading from the user's address space which can be expensive (and you can't rely on the NUL byte to stay in the same location if you want to look first and copy later) Casper
Powered by blists - more mailing lists