Files
rsync/support
Andrew Tridgell 33e54e68ca rrsync: deny device/special creation where creation happens
A restricted dir must not let a client have the spawned rsync create
devices or special files in the served tree, but -a bundles -D into the
client's short options, so refusing -D outright breaks every ordinary
`rsync -a`.  88cee089 forced --no-D instead.  That option also clears
the rdev framing, and rrsync sets it on one end only, so the file list
desynchronised: a FIFO push hung at protocol 29 and corrupted the list
at 30, and a device push failed at every protocol including 32.  Use
--drop-D, which withholds the creation without touching the wire.

Only on the receiving side.  A sender creates no received device or
special entry in the served tree, so there is nothing to deny and
--drop-D is a no-op there; forcing --no-D on a pull was the same
one-sided change in the other direction, and broke pulls the same way.
3.4.4 forced nothing at all and is the behaviour a pull now gets back.

rrsync-specials-denied asserted the option on a "--server --sender"
command line, which conflated the two directions.  It now checks that
the receiving side forces --drop-D and still forwards the client's own
-D -- without which the two ends frame the list differently again --
that the sending side forces neither, and, rather than only what is
forwarded, that a real push cannot create a FIFO while the rest of the
transfer succeeds.  An ordinary file alongside is the control, since a
push that failed outright would "deny" the FIFO too.

The device case gets its own push, because a device desynchronises at
every protocol while a FIFO only does so below 31.  It needs no mknod
privilege: rsync's fake-super "%stat" xattr is what makes a file a
device to rsync, and running the RECEIVER under --fake-super too lets it
record one without privilege -- so the case asserts that nothing of that
name appears, not merely that the transfer survived.

rrsync-pull-arg-shapes could previously assert only that pulling a FIFO
did not hang, because forcing the option on that side broke the transfer
outright.  It now requires the pull to succeed and deliver a FIFO, which
is what a pristine 3.4.4 rrsync does.

(cherry picked from commit 2fbb708f15)
2026-08-02 21:33:25 +10:00
..
2022-11-20 09:38:12 -08:00
2022-11-16 00:10:09 -08:00
2021-12-27 17:57:53 -08:00
2022-01-09 14:03:31 -08:00
2023-05-22 08:29:15 -07:00