Re: On PATH_MAX

[Bas Wijnen]

On Thu, Nov 10, 2005 at 01:35:59AM -0500, Jonathan S. Shapiro wrote:
> On Wed, 2005-11-09 at 16:41 +0100, Bas Wijnen wrote:
> > On Wed, Nov 09, 2005 at 03:02:36PM +0100, ness wrote:
> > > The problem Jonathan pointed out is that *others* will delay. This is not
> > > the case, as the server will be multithreaded.
> > 
> > Multi-threaded, or handling data in chunks with an event-loop, like the Glib
> > main loop that Gtk uses.
> > 
> > Jonathan, would that solve the problems you are talking about?
> 
> It will not.
> 
> I've already talked about multithreading. Now let me tackle event loops.
> 
> The problem is that somewhere in the event loop you need to check to see
> if you are blocking some other incoming request. This can be done with a
> non-blocking wait, but then the problem is that you need to store the
> state of the first activity while you go deal with the second. Or the
> third. Or the 30th....
> 
> So yes, I think we can dramatically increase the magnitude of the
> problem with just about any form of concurrency you care to try. We can
> convert a program that was not real time into a program that is both not
> real time and now is subject to storage denial of resource too!

Such state is indeed needed in this case.  But it can be stored on
client-supplied memory.  What is needed is that the state is copied into a
static server buffer when starting to handle the request, and copying it back
when the request is delayed again.  At those two moment do we need to accept
page faults, because the client can misbehave or be destroyed.  For the rest,
I think everything should be normal.

There needs to be a list of pointers to this client memory though, and I don't
think that can be moved to the client, because it must be kept until all
clients have left...  Sounds like the shared library problem.

Of course there still is a denial of resource attack possible by clients
sending excessive requests which fill up the queue, but I don't see why such
clients can't do the same type of attack (exhausting the server scheduling
time) by doing lots of requests, even in the scenario when the server enforces
a limit and there is no queue at all.

So let's look at a different approach: How about the client telling which part
of the name it wants to see?  First it has to ask for the first part, and when
that part says there's more, it can ask for the second, etc.  So the state
will be at the client side, and transferred in the request.  Clients which
don't want long filenames can ignore the "there is more" signal and use only
the first part.  Let's call the size of that part PATH_MAX. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature