Ubuntu
libfile-rsyncp-perl package

latent stderr bug breaks transfers with newer rsync clients

Bug #2007833 reported by Peter Thomassen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libfile-rsyncp-perl (Ubuntu)
New
Undecided
Unassigned

Bug Description

libfile-rsyncp-perl is used by backuppc version 3 (as packaged in 18.04 and 20.04). When backupping remote clients with rsync 3.2.3, File::RsyncP chokes on a change in stderr handling of that rsync version, and backups fail [1].

The failure is due to a long-standing, latent bug in File::RsyncP that did not surface earlier [2]. 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 has been a problem for users elsewhere as well [3].

A new version of File::RsyncP is available, fixing only this specific issue: https://metacpan.org/release/CBARRATT/File-RsyncP-0.76

It would be great if this fix could be released for Ubuntu 20.04 (and perhaps also 18.04). I'm not sure what the criteria for security releases are, but I think it should go through the security channel (as it impacts availability, and a denial-of-service bug for a backup service is pretty bad).

Thank you very much for your work on this package!

[1]: https://github.com/WayneD/rsync/issues/95
[2]: https://github.com/backuppc/backuppc/issues/369#issuecomment-692431546
[3]: https://<email address hidden>/msg32673.html

Peter Thomassen (mail-peter-thomassen)
information type: Private Security → Public
information type: Public → Public Security
Revision history for this message
Seth Arnold (seth-arnold) wrote : Bug is not a security issue

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

information type: Public Security → Public
Revision history for this message
Peter Thomassen (mail-peter-thomassen) wrote :

The bug allows an attacker with permission to delete a single (!) file on the backup client to kill the backup, leading to data loss of the rest of the backup, which may be all of it.

For example, if an IMAP user on a mail server creates a draft and deletes it (from their own mailbox) while a backup is ongoing, the backup will fail, and all users' (!) mailboxes will fail to get backed up.

On a reasonably busy mail server, there will always be files written and deleted while an hour-long backup is ongoing. Similarly, a web server with scripting support (e.g. PHP) will usually create and delete session state files, leading to the same problem as with the mail server across user boundaries.

I have actually run into this issue, where a backup was not possible for multiple days in a row. A less polite person has reported their frustration about it here: https://github.com/WayneD/rsync/issues/95#issuecomment-688906096

It seems to me that this is a real issue, and quite a clear case where on can (knowingly or unwittingly) "cross privilege boundaries [or] directly cause loss of data".

With this in mind, I'd like to ask you to reconsider. Thank you.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.