qmsk.rsync-ssh-command lvm source trailing slash incompatibility with rsync CVE-2022-29154 fixes #8
Description
Using USER@HOST:lvm:vgFoo/lvBar as an rsync source fails with an rsync protocol incompatibility error if the rsync client version includes the fixes for CVE-2022-29154:
ERROR: rejecting unrequested file-list name: <FILENAME>
rsync error: protocol incompatibility (code 2) at flist.c(911) [Receiver=3.1.2]
However, the command actually executed by the rsync wrapper looks like this:
/usr/bin/rsync --server --sender -vnlHogDtprxe.iLsfxC --numeric-ids . /tmp/lvm_lvFoo-backup_cbeytaai.mnt/
Note the additional trailing / on the rsync server source, which was NOT present in the original USER@HOST:lvm:vgFoo/lvBar rsync source. This triggers the protocol error, and using USER@HOST:lvm:vgFoo/lvBar/ (with trailing /) works as an rsync source.
The extra trailing / is added by the path logic in the rsync wrapper's LVMSource - due to the qmsk.rsync-ssh-command wrapper's use of temporary mountpoints for the LVM snapshots, it doesn't make any sense to send the mountpoint directory as-is, only its contents:
Line 287 in 47e991a
Line 315 in 47e991a
The mismatch between the client and server trailing slash worked just fine in earlier versions of rsync, but breaks the increased validation of file names required by the CVE-2022-29154 fix. This is not an rsync regression, but rather a qmsk-backup bug and resulting rsync incompatibility.
The rsync wrapper logic must be fixed to require the client to supply the trailing / for any send from an LVM snapshot source, with a clear error message if this is missing. The rsync wrapper must never attempt to insert any additional trailing /, as this will fail with the fixed rsync validation.