mirror of
https://github.com/RsyncProject/rsync.git
synced 2026-10-23 22:28:16 -04:00
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:
1 parent
9585b27678
commit
ef3f14e6a7
2 files changed
+10
-1
No files matched your search
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in new issue
Block a user