The way rsync disables the use of symlinks is to prefix each one with the string "/rsyncd-munged/". This prevents the links from being used as long as that directory does not exist. When this parameter is enabled, rsync will refuse to run if that path is a directory or a symlink to a directory.
When this parameter is disabled on a writable module and "use chroot" is off (or the inside-chroot path is not "/"), incoming sym‐ links 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 parameters.
munge symlinks = no, what is the tricky way to work around the protection described here? I.e to escape the module path, and read/write files outside of it?
EDIT: The vulnerability fixed by "munge symlinks" is CVE-2007-6199. "rsync before 3.0.0pre6, when running a writable rsync daemon that is not using chroot, allows remote attackers to access restricted files via unknown vectors that cause rsync to create a symlink that points outside of the module's hierarchy."