jimc
2022-Sep-24 05:12 UTC
Implicit containing directory sometimes rejected as unrequested
Version: rsync-3.2.6-1.1.x86_64 from OpenSuSE Tumbleweed, get it from
https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/rsync-3.2.6-1.1.x86_64.rpm
(or .src.rpm).
Symptom: In certain circumstances (see the reproducer script), rsync
from a remote source to a local destination and using a --files-from
list
sometimes rejects an implicit containing directory with this error
message:
ERROR: rejecting unrequested file-list name: usr/lib64
rsync error: protocol incompatibility (code 2) at flist.c(998) \
[Receiver=3.2.6]
Success or failure depends on arcane determinstic variations, and there
is a suspicion that the same input might produce different output at
different times. However, I repeated two variants 20 times a few secs
apart and they always worked or failed.
I've found these variant behaviors:
* With either sender version, receiver 3.2.5 always works and 3.2.6
sometimes fails.
* If both the source and destination are local, it always works.
* If the destination is remote, it works. Failures are seen with a
remote source.
* All my test cases have two implicit containing directories.
The first one has never been seen to fail but the second one does.
I haven't investigated if third or subsequent dirs would fail.
In one case where the second dir failed, exchanging the two filenames
led to both of them succeeding.
* I'm using rsync in a configuration management system and it needs some
options. If I remove -K -O --numeric-ids leaving only --rsh=ssh -a
--files-from, it fails or works equally.
* If I add --trust-sender then failing cases start working.
v3.2.5 has an addition to recognize if a rogue sender adds unrequested
toplevel names etc. (CVE-2022-29154) The option --trust-sender
disables the new paranoia. If this option is added to the execution
command line, spurious rejections disappear. Clearly the bugfixes in
file-list processing added in v3.2.6 had a bad interaction with the new
paranoia.
Attaching reproducer script rsyncbug.sh .
--
James F. Carter Email: jimc at jfcarter.net
Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsyncbug.sh
Type: text/x-shellscript
Size: 2982 bytes
Desc: not available
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20220923/5aef8dcf/rsyncbug.bin>
Wayne Davison
2022-Sep-25 18:24 UTC
Implicit containing directory sometimes rejected as unrequested
The git code should have this fixed. Feel free to build it yourself, or try the executable in the tar file from here: https://download.samba.org/pub/rsync/binaries/opensuse-15-x86_64/ ..wayne.. On Sat, Sep 24, 2022 at 5:02 PM jimc via rsync <rsync at lists.samba.org> wrote:> Version: rsync-3.2.6-1.1.x86_64 from OpenSuSE Tumbleweed, get it from > > https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/rsync-3.2.6-1.1.x86_64.rpm > (or .src.rpm). > > Symptom: In certain circumstances (see the reproducer script), rsync > from a remote source to a local destination and using a --files-from > list > sometimes rejects an implicit containing directory with this error > message: > ERROR: rejecting unrequested file-list name: usr/lib64 > rsync error: protocol incompatibility (code 2) at flist.c(998) \ > [Receiver=3.2.6] > > Success or failure depends on arcane determinstic variations, and there > is a suspicion that the same input might produce different output at > different times. However, I repeated two variants 20 times a few secs > apart and they always worked or failed. > > I've found these variant behaviors: > * With either sender version, receiver 3.2.5 always works and 3.2.6 > sometimes fails. > * If both the source and destination are local, it always works. > * If the destination is remote, it works. Failures are seen with a > remote source. > * All my test cases have two implicit containing directories. > The first one has never been seen to fail but the second one does. > I haven't investigated if third or subsequent dirs would fail. > In one case where the second dir failed, exchanging the two filenames > led to both of them succeeding. > * I'm using rsync in a configuration management system and it needs some > options. If I remove -K -O --numeric-ids leaving only --rsh=ssh -a > --files-from, it fails or works equally. > * If I add --trust-sender then failing cases start working. > > v3.2.5 has an addition to recognize if a rogue sender adds unrequested > toplevel names etc. (CVE-2022-29154) The option --trust-sender > disables the new paranoia. If this option is added to the execution > command line, spurious rejections disappear. Clearly the bugfixes in > file-list processing added in v3.2.6 had a bad interaction with the new > paranoia. > > Attaching reproducer script rsyncbug.sh . > > -- > James F. Carter Email: jimc at jfcarter.net > Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key) > -- > Please use reply-all for most replies to avoid omitting the mailing list. > To unsubscribe or change options: > https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20220925/689fade2/attachment.htm>