1. The file paths being sent and received were not "sanitized" to
	ensure that there weren't any ".." components that would escape the
	top level directory.  This can't happen with the standard rsync
	client, but it could be exploited on both read and write if someone
	modified an rsync client.  This fix sanitizes all incoming and
	outgoing paths when "use chroot = no".

    2. If a module is also "read only = no", clients could have created
	symbolic links with ".." components that would allow writing
	outside of the module.  This could happen with the standard rsync
	client.  This fix sanitizes all incoming symbolic link targets
	when "use chroot = no".

Previously, only top-level paths (anything passed in command line arguments)
were sanitized.  Sorry, I didn't think about the individual file paths
before now.