Upgrade to 3.1.3-8ubuntu0.5 causing sync errors

[Barry Price]

Hi

Several systems running Ubuntu 20.04 upgraded their rsync package from 3.1.3-8ubuntu0.4 to 3.1.3-8ubuntu0.5 overnight.

Automated syncs that connect to a 16.04 ESM server are now failing with:

receiving file list ...
ERROR: rejecting unrequested file-list name: [redacted]
rsync error: protocol incompatibility (code 2) at flist.c(916) [Receiver=3.1.3]

Reverting to the previous release (3.1.3-8ubuntu0.4) on the client side solves the problem.

This has been seen on multiple servers running 20.04 on amd64, I'll update this bug with details if we find it on other series too.

The 16.04 ESM server being connected to is using the rsync package version 3.1.1-3ubuntu1.3+esm2, so no recent upgrades on that end.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Marc Deslauriers (mdeslaur)]

I need to see the filenames that got rejected. You can send them to me in private if required. Thanks!

[Barry Price (barryprice)]

Provided requested details privately.

[Marc Deslauriers (mdeslaur)]

I'm going to need a reproducer for this issue so I can figure out what's not working in your specific example.

[Marc Deslauriers (mdeslaur)]

So after looking further into the way the systems affected by this issue are configured, this is what is happening:

1- rsync client is requesting a directory: rsync -v -rp sshuser@server:/var/cache/foo /tmp/foo
2- the server has an ssh forced command configured that is returning the contents of a different directory: rsync --server --sender -pr . /var/cache/bar
3- The updated rsync client now gets files from a different directory than what was requested, and is bailing out

The CVE-2022-29154 security update now validates that the server returns a list of files that match the list of files that were requested, instead of blindly accepting what the server sends, so I'm pretty confident the error message is normal. I will be recreating this scenario to confirm.

[Simon Déziel (sdeziel)]

Jammy's rsync (3.2.7) has --trust-sender that's described as: "trust the remote sender's file list"
However that won't be of much help as that's not available in older releases :/

[Marc Deslauriers (mdeslaur)]

I can confirm the scenario described in comment #5 is what is causing the issue. There are two ways to correctly fix it: 1- ask for the right directory that matches the forced command, or 2- use the new --old-args option that was backported to the security update, that should bypass the new security checks.

[Marc Deslauriers (mdeslaur)]

As this is working as expected, I am marking this bug as "invalid". Thanks!

[Haw Loeung (hloeung)]

See also LP:2009756 & https://github.com/bit-team/backintime/issues/1247