Skip to content

options.c: Fix --files-from confinement for local and SSH transfers - #1094

Open
seks99x wants to merge 1 commit into
RsyncProject:masterfrom
seks99x:fix-files-from
Open

seks99x wants to merge 1 commit into
RsyncProject:masterfrom
seks99x:fix-files-from

Conversation

@seks99x

@seks99x seks99x commented Sep 17, 2026

Copy link
Copy Markdown
Member

The rsync 3.5.0 path confinement patch of the files-from option treated the path as an operator-path for all cases (it only acts as an untrusted peer path in the daemon side), which makes it inconsistent with non-operator trusted paths behavior (log-file, filter, write-batch, read-batch, password-file, etc) when there is a root confined.

In local and ssh processes the path is coming from a trusted argument and shouldn't be treated as operator path.

┌──(root㉿192)-[~/rsync-latest-news/rsync]
└─# ./rsync -ai --confine-root=/home/omar --files-from=files.txt /home/omar/src /home/omar/dest/
rsync: failed to open files-from file files.txt: Too many levels of symbolic links
rsync error: syntax or usage error (code 1) at main.c(1905) [client=3.5.0-g4f6d572e]

Refused because the $cwd/files.txt is outside of the confined root.
                                                                                                                                                                            
┌──(root㉿192)-[~/rsync-latest-news/rsync]
└─# ./rsync -ai --confine-root=/home/omar --filter=". /root/rsync-latest-news/rsync/files.txt" /home/omar/src /home/omar/dest/
                                                                                                                                      
Filter file worked normally without being blocked from the root confinement

The recent path confinement patch caused an ELOOP error when local or SSH users tried to use a --files-from list located outside the confined root.

This happened because the code treated the argument as if its always an operator-path peer. CLI arguments provided locally or over SSH are trusted, so the strict boundary check should only apply to untrusted clients connecting to a background daemon.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant