rsyncd bug for sym-links

[cbarratt at users.sourceforge.net]

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