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

daemon should sanitize its symlinks, as it used to do.
This commit is contained in:
Wayne Davison committed 2007-11-27 13:11:49 -08:00
1 parent 9585b27678
commit ef3f14e6a7
2 files changed
+10 -1

No files matched your search

+4 -1
View File
@@ -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
+6
View File
@@ -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