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: <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