rsh relies on stdin being blocking
ssh relies on stdout being non-blocking
what we've done before is to set both stdin and stdout to either
blocking or non-blocking. Now I set stdin to blocking and stdout to
non-blocking. This seems to fix all cases I've tested.
ssh clag problems as long as you also fix the same problem in sshd
removed all the old read buffering code from io.c as this was only
there to try to reduce the chance of clagging up sshd.
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.
The reason for that is that on SVR2-based UTS 2.1.2 (which along with many
other old systems implements getcwd by forking "pwd") getcwd hangs when
called when other child processes are running.
I also added a quick return from push_dir if name == NULL so it doesn't
actually have to chdir anywhere when just initializing.
An initializing call to push_dir("/",0) had previously been put in at the
beginning of daemon_main() to avoid calling getcwd after a chroot, but
since that is no longer I needed I removed it and changed the call to
chdir("/") after chroot into a push_dir("/",0) so it will remember the
correct current directory.
trailing slash. This caused a problem when using "use chroot" and sources
that contained a trailing slash (which prevents the last filename component
of the source from being included in the destination). Instead, have
sanitize_path() remove "." components and duplicated slashes ("//") itself.
unsigned comparisons. Transferring files between two machines that
treated strcmp() differently led to the files being given the wrong
name at the destination if the filenames had characters > 128 (such as
Kanji characters) and the source and destination machines treated
strcmp() differently (ie. one treated strings as signed and the other
as unsigned).
We now treat all string comparisons for file list sorting as unsigned.
we no longer use non-blocking IO, instead it uses select a lot more,
being careful to always allow for reading whenever a valid read fd is
available and chcking timeouts.
also split the file io calls into fileio.c
messages from the server when using the socket code.
I've doen a fair bit of testing and I don't seem to have broken
anything, but it is a very complex change. More testing needed!
then we supply a zero filled buffer at the end and rely on the
checksum to cause a retry. This is really the best we can do as there
is no correct semantics for copying a changing file!
