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>