Re: On PATH_MAX

[Marcus Brinkmann]

At Thu, 3 Nov 2005 09:58:01 -0700,
"Christopher Nelson" <address@hidden> wrote:
> 
> > "Alfred M\. Szmidt" <address@hidden> writes:
> > 
> > > Make it possible to set the amount a user is able to 
> > allocate instead 
> > > of setting any kind of static limit that is impossible to get away 
> > > from without recompiling the whole system.
> > >
> > > Arbitrary limits are poor software design, and have always been.
> > 
> > I tend to agree here.  :-)
> > 
> > Whether the OS architect likes it or not, applications that 
> > use the file system the way GNU Arch does _do_ exist.  And 
> > it's not up to the OS architect to decide whether they should 
> > exist at all.
> 

> If you want an operating system that let's you do whatever you want,
> you should just stick with DOS. ;-) More seriously, if you wish to
> be actively hostile, what is stopping you from creating a path as
> large as available memory and passing it across the protection
> boundary?  Such an act would cause severe denial of resource as the
> system thrashes it's swap and spends quite a long time parsing and
> breaking down the path.  It would likely cause the receiver to fail.
> Even if the receiver restarts, the hostile app could wait for it to
> come back and retry the same operation.  Supporting arbitrarily
> large messages of that sort are dangerous in a silly way.  A
> reasonable limit is necessary.

It's not dangerous if I don't pass the path as a string, but the
resource containing the path.  And the resource containing the
scheduling time to process the path ;)

In other words: It is all a matter of what your trust boundaries are,
how your communication protocols look like, and what operations you
perform.

To say that the one or the other is stupid is just plain wrong.

Sometimes you should support dynamic reallocation.  Sometimes you
should have a fixed buffer and truncate.  You should not limit your
toolset because of some half-cooked and (generally) _wrong_
programming dogmas.

Thanks,
Marcus