mirror of
https://github.com/RsyncProject/rsync.git
synced 2026-09-17 23:57:46 -04:00
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`.88cee089forced --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 commit2fbb708f15)