On Fri, 2004-06-11 at 06:40, Branko Čibej wrote:
> This doesn't do much to avoid the DoS.
It make the network act as a throttle on resource usage by not
allocating all the memory at once. But you're right; particularly in
threaded mode (where you can't just set a resource limit), it's not a
very comprehensive solution.
> Might I suggest we finally decide what the maximum in-memory
> object size should be? I'd suggest twice the stream chunk size.
There are some complicating issues here:
* Someone committing a DOS attack is going to use multiple
connections, so if we have a fairly large limit, it will still be pretty
easy to carry out a DOS.
* Property names and values are stored in memory, so any in-memory
object size limit we impose is also a quality-of-implementation limit on
properties. Not something to impose in a 1.0.x release.
* read_item is also recursive, so you can consume on the order of 48
bytes of stack space per '(' you send during the greeting.
Here is my current thinking: we add a memory limit to the ra_svn
connection structure and a new marshal.c function to set it. The memory
limit applies to the total amount of memory consumed by an item read
from the connection, not just to one string.
There's no externally configurable knob (I don't believe in providing
performance-tuning knobs when it's not absolutely necessary); the
hardcoded values would look like:
* The client imposes no limit on communication from the server.
* Before initial authentication, we impose a very small limit,
on the order of 4-8K.
* After authentication (even if it's anonymous), if the connection
has read access, it gets a medium limit, on the order of 64K.
* If a connection has write access, we impose no limit.
So, no limitation on property names and values (once you're sending
those across the wire, you're either the server talking to the client or
you have write access), it becomes very difficult to DOS a server which
requires read authentication, and modestly difficult to DOS an
anonymous-read-only server. (And still easy to DOS a server which
allows anonymous commits, but that's hardly a surprise.)
For the recursion problem, we could either impose a static recursion
limit (the ra_svn protocol never uses more than about four levels of
recursion), or consume 50 bytes of the memory limit for each open
paren. Since stack space is sometimes more precious than heap space,
probably introducing a static recursion limit (of, say, 64) is the best
choice.
Hopefully there will be less code involved than prose. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 11 17:33:17 2004