At 07:50 AM 19/04/2006 -0400, Marc Sherman wrote:
>Jonathan Gilbert wrote:
>>
>> This of course doesn't do anything to stem an intentional denial of
>> service attack (apart from forcing such a malicious person to make
>> many short-lived connections rather than just one long one -- if the
>> number of connections from each IP were itself rate-limited, that
>> could potentially deal with non-distributed DoS attacks), but rather
>> prevents accidental requests from blowing up the server and also
>> allows legitimate long-running requests to proceed at a lower speed
>> without preventing anybody else from effectively using the system.
>
>As an svn admin on a private network, I don't care about intentional DOS
>at all; we've got HR procedures to handle that. What I do care about is
>people accidentally checking out the root of the repository, and then
>going to get coffee and filling up their own disks -- a rate limiter
>doesn't help with that. I want a way to configure the server to reject
>checkouts of certain parts of the repository. These checkouts should be
>allowed with a --force command, as this _isn't_ access control, it's
>there to help people avoid making common mistakes.
I guess what is needed is some sort of flag to 'checkout' that can be
passed to hook scripts on the server side. My understanding is that the
Subversion policy is fairly firm that this sort of thing should *not* be a
part of the Subversion binary itself, but at present, it is a deficiency
(perhaps by design) of the hook system that arguments cannot be passed
directly to it from the *client* side.
I still believe that rate control like I described would effectively
mitigate the problem you are worried about. I mean, users make mistakes,
but they're not all going to make that same mistake at the same time, are
they? One user doing a long-running (and this rate-limited) checkout of,
say, /source/trunk instead of /source/trunk/specificproject will come back
from getting coffee to find it 10% done and going at only 100 k/s instead
of saturating the network and slowing the server down significantly. At
that point, he/she *should* notice that something is amiss and cancel the
operation. Even if they don't, it doesn't stop anybody else from using the
server at near to full speed in the mean time.
Basically, what you're suggesting would be analogous to an FTP server that
would by default refuse to let users initiate downloads of files larger
than a certain size, unless they ran some custom SITE command first.
Perhaps some people would like that feature; I personally would be annoyed
all to hell by it and might even intentionally download a lot of large
files just to get even with the site operator ;-)
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 21 19:02:06 2006