It is possible to escape rrsync restricted folder by syncing (using rsync -a ...) a symbolic link to the parent folder and then syncing with this symbolic link. Concretely, we could do: ln -s .. parent rsync -acrvz . login@server: and then we can rsync with login@server:parent to read/write files in the parent folder of the restricted folder.
Created attachment 12132 [details] hardcode safe-links Adding '--safe-links' or '--munge-links' on server side should fix this. I actually hardcoded it on some of my servers. The version of rsync present didn't have the --munge-links option so I used --safe-links. I'm not proposing this change be included, it's just a quick'n'dirty hack while someone more experienced has an actual fix.
Created attachment 14648 [details] rrysnc patch to avoid following symlinks out of the restricted dir This patch fixes it a different way, by preventing rrysnc from following symlinks out of the restricted dir rather than by blocking their creation. This comes at the cost of adding a lock to prevent any other rrsync running at the same time as a write rrsync. Without that, an attacker could bypass the check by replacing a directory with a symlink after rrsync has checked it but before rsync has opened it. It's still somewhat less secure than adding --munge-links, because it's more complex.
Created attachment 14658 [details] revised patch that also abs_path checks option args revised patch: I forgot to abs_path check file option args
Created attachment 14662 [details] rrsync patch again, third time's the charm Revised patch again, disallow any rsync option that might cause it to follow a symlink out of the restricted dir.
The latest rsync has a default lock similar to what you proposed (it just locks the restricted dir, not a separate file) and the improved arg checking and rejected symlink-copying options. It also accepts a "-munge" option (in the accepted_keys file) that can be used to enable rsync's symlink munging, possibly combined with a new "-no-lock" option to disable the new single-use instance locking. Thanks for your patch, and apologies that it is so late.