clients when writing to a rsync server
it works like this:
- we have an extra pipe from the receiver to the generator
- the server always runs with multiplexing on
- errors from the generator go down the multiplexed connection
- errors from the receiver go over the pipe, and from there to
the multiplexed conn
it required some incredibly ugly code. damn.
couldn't find some of them (especially <fnmatch.h>, because it wasn't
looking in the current directory). The header files are included better
from ../rsync.h.
FNM_PATHNAME flag (to stop at slashes in path names) was not working.
Ironically, the bug in glibc's fnmatch was reported on the rsync mailing
list in late October, and rsync's configure.in was changed to detect the
bad glibc and use the internal fnmatch, but the internal fnmatch was based
on the same buggy glibc!
than skipping it and thus not updating it. For example, the ownership or
mode on a file may prevent opening it, but the directory may still be
writable so the file could be completely replaced.
the file if the file has the setuid or setgid bits set as the chown
has a side effect of removing the setuid and setgid bits.
we re-do the stat in this case
was not preserving group permisions. Bug was introduced March 1 in
version 1.100 of rsync.c with an error in re-ordering of the boolean
expressions. In order to completely preserve the earlier semantics,
change_gid should depend on "(am_root || !am_daemon)", but I don't see why
group ownership should behave differently in a non-root daemon.
One is a note that a leading "/" in a symlink target will not behave
exactly as if a chroot had occurred, but I decided it wasn't worth the
making it the same.
The other is note about an extra harmless trailing "." that is added under
some rare circumstances.
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.
Andrew Tridgell