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.
hadn't changed but its permissions had, the file wasn't copied but
its permissions were attempted to be set anyway. Made a change to
skip setting the permissions in that case.
--compare-dest. It was due to an incomplete analysis of the problem,
sorry. I left a comment in its place indicating that normally the
parent directories should already have been created.
It turned out to actually be a bug in nsbd in which it was not always
including all the parent directories in the include list like it was
supposed to. The files themselves were still being sent but that was only
because my exclude_the_rest optimization was kicking in; if it weren't,
excluding the parent directories would have had the side effect of
excluding the files too. So it really had nothing to do with the
--compare-dest option after all, just with the requirement that if you use
--exclude '*' you need to explicitly include all parent directories of
files you include.
target destination were not getting created. There was a case in
receiver.c to do that but it was only getting invoked when the -R option is
specified, although I don't know why it was limited to that.
It's too bad I didn't get a chance to more fully test the use of
--compare-dest by my nsbd program before releasing rsync 2.3.0. I'll
probably need to put a workaround in nsbd too until the next release
of rsync.
of cygwin doesn't work. Thanks to Martin Krumpolec <krumpo@pobox.sk> for
the patch. At the same time, include cache checks in configure.in for a few
items that were missing the checks.
the receiver even when not combined with -r. Without this, the directories
were getting created mode 777 because the default umask on receivers is
often 00.
I believe this is the latest, which comes with automake 1.4 (somebody
else is in charge of installing the GNU stuff on my system so I'm not
100% sure it's the absolute latest, but it was updated just a couple
weeks ago).
other access resulted in group and other access being left off when the
'-p' option was not used. This fixes it by reintroducing the ACCESSPERMS
mask and setting permissions to (file->mode & ACCESSPERMS) if preserve_perms
is off. I decided to change the mask INITPERMMASK to INITACCESSPERMS at
the same time. When preserve_perms is off, rsync is restored to the
previous behavior of having the permissions of the original file with the
umask and setuid/setgid bits shut off.
Also, I decided that a check for "(updated && (file->mode & ~ACCESSPERMS))"
is no longer needed since as far as I can tell that would have only affected
permissions when not running as root and when a chgrp was done to a group
the user was not a member of, using system V chgrp semantics. This is no
longer allowed.
as calculated by the configure macro AC_TYPE_GETGROUPS. Without that, it
doesn't work properly on systems like sunos 4 where gid_t is defined to
be an unsigned short but getgroups is defined to return an array of integers.
an obscure race-condition security hole where a file may for a short time
have the wrong group. Could have used 707 instead but that's just too weird
of a permission. The define name used to be ACCESSPERMS but that is defined
as 777 on Linux, so changed the name to INITPERMMASK.
does not belong to, in these two ways:
1. If a group mapping doesn't exist for a group name, do not preserve
it for a non-root receiver. This is especially evident with the
sender is a daemon using chroot because then no mappings are
available.
2. Before setting the group on a file make sure that it is in the list
of groups returned by getgroups(). The same thing is done by chgrp
on systems that support bsd-style chown/chgrp, and this enforces
that it happens the same way on all systems. Overhead is very
little, especially since most systems don't allow more then 16
groups per user.
