When the new "munge symlinks" option is off, a non-chroot

daemon should sanitize its symlinks, as it used to do.

diff --git a/flist.c b/flist.c
index 72dded8..4eaca20 100644 (file)
--- a/flist.c
+++ b/flist.c
@@ -927,8 +927,11 @@ static struct file_struct *recv_file_entry(struct file_list *flist,
                        bp += SYMLINK_PREFIX_LEN;
                        linkname_len -= SYMLINK_PREFIX_LEN;
                        read_sbuf(f, bp, linkname_len - 1);
-               } else
+               } else {
                        read_sbuf(f, bp, linkname_len - 1);
+                       if (sanitize_paths)
+                               sanitize_path(bp, bp, "", lastdir_depth);
+               }
        }
 #endif
 

diff --git a/rsyncd.conf.yo b/rsyncd.conf.yo
index 052ccc7..b3eb4dd 100644 (file)
--- a/rsyncd.conf.yo
+++ b/rsyncd.conf.yo
@@ -190,6 +190,12 @@ every symlink's value.  There is a perl script in the support directory
 of the source code named "munge-symlinks" that can be used to add or remove
 this prefix from your symlinks.
 
+When this option is disabled on a writable module and "use chroot" is off,
+incoming symlinks will be modified to drop a leading slash and to remove ".."
+path elements that rsync believes will allow a symlink to escape the module's
+hierarchy.  There are tricky ways to work around this, though, so you had
+better trust your users if you choose this combination of options.
+
 dit(bf(max connections)) The "max connections" option allows you to
 specify the maximum number of simultaneous connections you will allow.
 Any clients connecting when the maximum has been reached will receive a