[Server-devel] [PATCH] Touch a ".transfer_complete" to mark completion, minor cleanups

[Martin Langhoff]

On Mon, Jun 16, 2008 at 6:03 PM, Michael Stone <michael at laptop.org> wrote:
>> In any case, all of this can merely prevent a "friendly fire" DoS.
> As it turns out, the GET to the /new/* URL serves as a "commit message"
> to inform the server that the client is satisfied that it has
> transmitted all necessary backup information. It's arguable whether
> there's any security impact because the user's SSH key and their UUID
> are so poorly protected on current systems. However, I think that it
> does have substantial reliability impact: if the client powercycles
> while transmitting, in your current protocol description at
>
>  http://wiki.laptop.org/go/XS_backup_restore
>
> the server's most recent backup would be left in an inconsistent state.
> Would the client receive broken data on the next restore? If not, why
> not?

Note: this is a work in progress. Perhaps the email prefacing this
patch-series for ds-backup wasn't clear enough - it sure didn't appear
the way I wanted with all the patches as replies to the preface. Draft
code - a lot of it earmarked to be ripped out :-/

Back to your question: we tack on a "transfer_complete" flag file in a
2nd rsync transmission that is conditional on the first one
succeeding. A better solution is to wrap rsync at the XS end, and flag
"completion" if the local rsync exits cleanly.

>> true DoS protection from clients we need an rsync wrapper
>
> Throttling login rate would take care of the problem. Hashcash at the
> initial GET stage can be used to implement more sophisticated
> throttling.

Hmmm. Nothing prevents clients from just ssh'ing in and rsyncing to
various nested directories to DoS our storage. Heck, without rssh they
get shell, so they can eat up the partition with a quick dd
if=/dev/zero of=bla

All the http stuff is for _nice_ clients that are trying not to be
rough on the XS. If you tell me that our threat scenario is more
serious, we are in for a complete change of plans.

> We should be very wary of deploying a known-vulnerable
> protocol which backward-compatibility might force us to keep.

Vulnerable or nice?

>> easy to do, a bit harder to secure. We'll need rssh to lock down
>> things in this area, and as far as I can see, rssh ain't too friendly
>> with wrappers in high-level languages.
>
> It's not really that we need to control what happens once the user has
> logged in; rather we need to control the rate at which logins occur,
> yes?

No. We are talking ssh+rsync. Nice clients will obey our rate control.
Bad clients will go for ssh directly, and mar our day. In a bad way.

cheers,




m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff