qmsk.rsync-ssh-command lvm source trailing slash incompatibility with rsync CVE-2022-29154 fixes

[SpComb]

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:

backup/qmsk/backup/rsync.py

Line 287 in 47e991a

self.path = path.lstrip('/')

backup/qmsk/backup/rsync.py

Line 315 in 47e991a

yield mountpoint.path + '/' + self.path

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.

[SpComb]

Symptoms similar to RsyncProject/rsync#376, but cause is entirely different.

Interestingly it seems like rsync --old-args also works - it doesn't seem to have any effect on the rsync server command, but I suppose it has some effect on the client file-list validation?