Regression in stderr handling in 3.2.3 breaks BackupPc on 22.04; fix available in 3.2.4

[Peter Thomassen]

rsync 3.2.3 (packaged in Ubuntu 22.04) changes stderr handling, leading another bug in libfile-rsyncp-perl (in Ubuntu 18.04 and 20.04) to surface [1].

It practically makes using BackupPC 3 impossible with clients using rsync 3.2.3, as is packaged for 22.04. The fact that BackupPC on 20.04 can't be used to back up machines with 22.04 is rather surprising and has bitten other users [2].

It's unclear whether the bug will be fixed in 18.04's and 20.04's libfile-rsyncp-perl package (for status, see [3]).

Because of this, the rsync maintainer has included a patch in 3.2.4 that fixes this regression [4] (even though not strictly an rsync bug). As a result, rsync 3.2.3 is the only affected version, which happens to be the one packaged in 22.04.

This report is to request backporting that fix [4] to Ubuntu 22.04, so that things don't silently break in scenarios where the backup server is left at 20.04, and some backup clients happen to upgrade to 22.04.

I'm not sure what the criteria for security releases are, but as the issue causes backup denial of service and has easy mitigation, I think it would make sense to put it through the security channel.

[1]: https://github.com/WayneD/rsync/issues/95#issuecomment-699185358
[2]: https://<email address hidden>/msg32673.html
[3]: https://bugs.launchpad.net/ubuntu/+source/libfile-rsyncp-perl/+bug/2007833
[4]: https://github.com/WayneD/rsync/commit/4adfdaaf12db26c348b4d6150119b377f9b622c8

[Bryce Harrington (bryce)]

Thanks for the links Peter. Looking at the upstream patch, it looks straightforward enough, but can you also provide more detailed steps to reproduce this issue?

I gather this would involve setting up a 20.04 host and 22.04 clients, running Backuppc on the latter to pull data from the former. If you can provide a reproducer that'd help accelerate progress towards getting a fix prepared for backporting. Thanks ahead of time.

[Peter Thomassen (mail-peter-thomassen)]

Thank you for looking into this. The test case is described in https://github.com/backuppc/backuppc/issues/369#issuecomment-693663922 and boils down to:

> * Create temporary file on host [i.e. backup client, with rsync 3.2.3]
> * Run `/usr/share/backuppc/bin/BackupPC_dump -v -f host` manually on the server cmdline as correct user [use BackupPC v3 with buggy libfile-rsyncp-perl, as present in Ubuntu 18.04 and 20.04)
> * Wait for rsync to start dumping files (i.e. indexing is complete), then delete temporary file on host

HTH.

[Paride Legovini (paride)]

Thanks. According to the package versions the bug is not present in >= Kinetic, so setting the devel release task as Fix Released.

[Simon Déziel (sdeziel)]

I /think/ there is work being done by security to land a MRE for rsync, you might want to sync with @mdeslaur.

[Sergio Durigan Junior (sergiodj)]

Thanks for the heads up, Simon. I talked to Marc and he confirmed that he intends to MRE rsync, so I reassigned this bug to him.

[Marc Deslauriers (mdeslaur)]

Yes, I plan on releasing 3.2.7 to jammy and kinetic as a security update possibly next week, so that should take care of this issue at the same time.

[Peter Thomassen (mail-peter-thomassen)]

fixed: https://launchpad.net/ubuntu/+source/rsync/3.2.7-0ubuntu0.22.04.2