[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0b5f01c4d25b$227eaac0$3e0aa70a@doug>
Date: Wed, 24 Nov 2004 14:23:52 -0500
From: "Doug Moen" <doug.moen@...ecoat.com>
To: <Martin.Buchholz@....COM>, <Casper.Dik@....COM>
Cc: srevilak@...akeasy.net, James Youngman <bugtraq@...ession.spiral-arm.org>,
parimiv@...haw.com, levon@...ementarian.org,
bugtraq@...urityfocus.com, bug-findutils@....org
Subject: Re: Changes to the filesystem while find is running - comments?
> Like other arbitrary system limits of its ilk, PATH_MAX
> is evil, and is one of the more persuasive arguments for
> getting rid of the C language and its fixed-size
> stack-allocated buffers.
>
> char path[PATH_MAX]; /* considered harmful */
>
> Martin
The PATH_MAX limit may not be motivated by the limitations of the C
language.
I remember during my student days that we had BSD Unix running on a VAX.
Early versions of BSD did *not* have a PATH_MAX limit.
One day, someone discovered that you could launch a Denial Of Service
attack against the kernel using (I think) chdir("./././././. ..."),
where the length of the argument string was many megabytes.
This was a big deal, because the VAX was a time sharing system with
many simultaneous users, and this attack could effectively halt the machine
for several minutes.
Not long after that, our kernel was upgraded to enforce a PATH_MAX limit.
Modern kernels seem to have arbitrary fixed limits for just about
everything.
My understanding is that this is sound engineering practice. It protects
the
system against rogue processes, and contributes to security and stability.
Doug Moen
Powered by blists - more mailing lists