Kirby Bakken writes:
> I'm 99% sure there is a bug in rsync when running in daemon mode on a
> 'remote' server. The bug is that when trying to rsync a sym-link,
the
> daemon 'leg' of the code strips off the leading path separator (for
linux,
> this would be a '/'). I have produced a 'fixed' version of
the code and
> we have been using it for at least 6 months. We've also used the same
> code to rsync sym-links in 'non-daemon mode' and it appears to work
fine.
> Although I'm pretty certain of the fix for daemon rsync, I am unsure if
my
> fix affects non-daemon operation..... At any rate, for your
> consideration, here is the description of the fix:
This behavior is intended. See man rsyncd.conf:
use chroot
If "use chroot" is true, the rsync server will chroot to
the
"path" before starting the file transfer with the client.
This
has the advantage of extra protection against possible implemen-
tation security holes, but it has the disadvantages of requiring
super-user privileges, of not being able to follow symbolic
links outside of the new root path when reading, and of implying
the --numeric-ids option because /etc/passwd becomes inaccessi-
ble. When "use chroot" is false, for security reasons
symlinks
may only be relative paths pointing to other files within the
root path, and leading slashes are removed from absolute paths.
The default for "use chroot" is true.
Craig