Implicit containing directory sometimes rejected as unrequested
jimc via rsync <[email protected]>
| Newsgroups | gmane.network.rsync.general |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected]
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
rsyncbug.sh
(text/x-shellscript, 2.9 KB)
#!/bin/bash
# rsync-3.2.6-1.1.x86_64 shows the bug; rsync-3.2.5-1.1.x86_64 works perfectly.
# The --files-from list has just files, but one of the implicit containing
# directories will be rejected 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]
# Receiver 3.2.5 works with either sender. Receiver 3.2.6 fails with either.
# Not every --files-from list sets off the bug.
: ${HOSTNAME:=$(uname -n)} # Name of this host for "remote" execution
j=/var/tmp/root.jimc # Directory to put the test files in
mkdir -p $j
cd $j
# Actual filenames that failed in the config management system
if /bin/true ; then # *** Turn on one of these
cat - > $j/filesfrom.ls <<EOF
usr/lib/security/pam_runscript.so
usr/lib/security/pam_runscript.so.i586
usr/lib64/mesa/bin/data
usr/lib64/sasl2/cgi-helper
usr/lib64/sasl2/cgi-helper.x86_64
usr/lib64/security/pam_runscript.so
usr/lib64/security/pam_runscript.so.x86_64
EOF
fi
# Simplified filenames for reproducer.
if /bin/false ; then # *** Turn on one of these
cat - > $j/filesfrom.ls <<EOF
lib/testlib.txt
lib64/testoib64.txt
EOF
fi
# Sets up the source content. The destination is created implicitly. Fails
# or succeeds equally whether or not dst already exists.
rm -rf $j/{src,dst}
while read fname junk ; do
fname=$j/src/$fname
mkdir -p ${fname%/*}
echo "Test File $fname" > $fname
done < $j/filesfrom.ls
# Testing rsync...
rsync --rsh=ssh -a -K -O --numeric-ids --files-from=$j/filesfrom.ls $HOSTNAME:$j/src/ $j/dst/
echo "exit code = $?"
# Outcomes:
# "rsync --options $j/src/ $j/dst/" works perfectly on either file list.
# "rsync --options $HOSTNAME:$j/src/ $j/dst/" rejects dirname of 2nd file
# (lib/ OK, lib64/ rejected). This order and remote src are used for
# variant tests except as noted.
# But if lib64/ is before lib/ then both are transferred.
# "rsync --options $j/src/ $HOSTNAME:$j/dst/" transfers both files.
# Aargh, there's a suspicion that it may be intermittent! Got to test a lot
# of repetitions. These were a few seconds apart, using the actual filenames.
# 1 = failed on first dir, 2 = failed on 2nd dir, x = transferred both files.
# x x x x x x x x x x x x x x x x x x x x x (21 trials, remote dst)
# 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 (20 trials, remote src)
# If most options are removed, leaving only --rsh=ssh -a --files-from,
# it fails or succeeds equally. Failed with orig. filenames, remote src,
# /usr/lib64 second. Worked with simplified names.
# Big clue! 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.