RE: On PATH_MAX

[Christopher Nelson]

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

Sure, but in practice how does this work?  The sending app gives you as much 
processing time as it has to process THAT path?  Does that mean that all paths 
are processed in a thread-per-path?  If not, how does the receiving thread 
*practically* break up it's operations to obey that scheduling quanta? If it 
doesn't break them up, it starves out other clients. If so, when I create a 
path as large as available memory and then pass it to you, you *STILL* have a 
problem.  Somehow you have to get access to that path, and chances are you 
don't have enough virtual memory to map it in.  Even if you *DO*, you still 
have the problem that other threads working on other paths require actual 
physical memory (not to mention other useful apps), which requires swapping in 
and out to allow them to work. Finally, even if that doesn't cause a noticeable 
problem, how many sane path algorithms can validate a path in place without 
using additional memory?  Granted, it can certainly be done, but in *practice* 
it's unreasonably difficult.

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

I think it is wrong to have an arbitrary global limit, but I don't think that 
an application imposing an arbitrary *reasonable* limit is wrong.  Because we 
*can* do something is not a good argument for actually doing that something.

-={C}=-