From 05dabb0fdb135f69015997a129cbd7d83561df28 Mon Sep 17 00:00:00 2001 From: Andrew Tridgell Date: Tue, 28 Jul 2026 08:55:14 +1000 Subject: [PATCH] NEWS: state what the rrsync pin actually covers The CVE-2026-53783 entry claimed rrsync "inode-pins each validated component and exec's against the pinned fd". It pins the path and roots the argument there, which is not the same thing for a sender argument, and the primitive is Linux-only -- elsewhere rrsync keeps the realpath()-validated name, as it always did. --- NEWS.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/NEWS.md b/NEWS.md index 4c70a689..d5c85526 100644 --- a/NEWS.md +++ b/NEWS.md @@ -117,9 +117,16 @@ a symlink that a privileged rsync then follows: - CVE-2026-53783 (MEDIUM): rrsync restricted-directory escape. It validated each argument with `realpath()` and then exec'd rsync against the same name (a TOCTOU window), and left dangerous options enabled in a restricted subdir. - rrsync now inode-pins each validated component and exec's against the pinned - fd, denies `--copy-unsafe-links`, forces `--no-D`, and refuses a symlinked - `--log-file`. + rrsync now inode-pins the validated path and roots the argument it hands rsync + at that pinned fd, denies `--copy-unsafe-links`, forces `--no-D`, and refuses a + symlinked `--log-file`. The pin relies on Linux's `/proc/self/fd` magic links + being bound to the open inode, so it is Linux-only; on the BSDs, macOS, Solaris + and Cygwin rrsync passes the `realpath()`-validated name as it always did. + Two limits are worth stating: under `--relative` only the anchor the + transmitted name starts from is pinned, so a component below it can still be + raced, and the final component of an ordinary sender argument is not pinned + either (rsync does not follow a symlink there, and the options that would + change that are refused in a restricted dir). Daemon protocol / identity: