RE: On PATH_MAX

[Christopher Nelson]

> On Mon, 2005-11-07 at 09:32 -0700, Christopher Nelson wrote:
> > Now, imagine that Thread A prepares a service request plus data for 
> > Thread B.  Imagine that this request is deliberately crafted to 
> > involve all available address space.  Thread A delivers the 
> request to Thread B.
> > In order for Thread B to even *consider* the request, it 
> must map the 
> > memory into it's own address space.
> 
> In order to map the data, thread B must know the size of the 
> payload, and can therefore determine that the mapping 
> violates the contract.
> 
> >   Now, let us say that Thread C needs
> > to communicate with Thread B as well.
> 
> This assumes that thread B is obligated to *retain* an 
> excessively large mapping after the end of its interaction 
> with thread A. Once A has violated the contract, I would say 
> that thread B is very much within its rights to terminate the 
> session with A, decommit all state held on behalf of A, and 
> ummap A's data.
> 
> It is possible to design protocols that are flawed in the way 
> that you describe, but they are self-evidently broken.

Yes, this is my point exactly.  Requiring support for arbitrary sized
string transfers is a broken mechanism.  I don't feel that it's a good
idea to expect a server to simply accept whatever you throw at it.  Up
to and including bazillion-character-long paths.  The example was
designed to highlight that, and it seems to have successfully done so.

-={C}=-