Andrew Tridgell
bb806288b7
A filter rule that fails to parse was printed back verbatim. When the rule came from a file rather than an argument, that text is file CONTENT, and the peer picks which file gets merged: a per-directory merge rule travels over the protocol, so no argument of ours ever names it and nothing a wrapper can see mentions it either. Any line that is not valid filter syntax therefore came straight back to the peer -- a read-any-line oracle over an rrsync restricted account or a daemon module, neither of which confines the merge open. The syntax errors turned out to be the smaller half. The MATCH trace names the pattern that acted, and report_filter_result() logs at level 1 for a sender or generator, so plain -vv -- no --debug, nothing a stock client cannot send -- returns a server-side merge file's rules: [generator] protecting file X because of pattern <the file's text> So provenance is carried on the rule itself (FILTRULE_FROM_FILE), not just in the parser: a deferred ":" merge is processed long after the file that named it was read, and its own name is file content too. TEXT_FROM_FILE() consults the parse-time context and the rule, so both the immediate and the deferred paths redact. Rather than test the provenance at each message -- which is how the last few of these were found, one at a time, after the ones before them were fixed -- every string that is or is built from a rule's own text goes through rule_text(). It returns the text for an argument-supplied rule and a description of where it came from otherwise, so a message added later cannot reintroduce the leak by forgetting to check, and there is one place to audit. rule_detail() does the same for the extra detail a message adds ABOUT the text: a character of it, an offset into it, the [not found] bit. Thirteen sites now route through them: the syntax errors; the modifier character (one byte of the file, a slower oracle but still one); the failed-open and merge-depth messages, whose pathname is file content whenever a rule named it -- and errno with them, since it answers "does this path exist"; both over-long messages, the deferred one of which needed no verbosity at all; both merge-name overflows; the long-named directory error; the [not found] openability bit; the match trace; the add_rule, parse_filter_file and daemon-hidden traces; and the per-dir mergelist label, which had the name baked in. rule_detail() covers more than it first looks: the trailing-whitespace CAUTION is computed from the rule's last byte, and "hidden by daemon filter" distinguishes a daemon-filter rejection from an ordinary open, so both would answer questions about text the peer cannot see. The regression proves the chokepoint rather than the sites: making rule_text() return its input unconditionally fails the test. It also pins what must NOT change for the user's own rules -- the whitespace warning still fires, and an over-long argument rule is still reported at full length (the helper buffers at BIGPATHBUFLEN, as rprintf does, so redaction does not quietly truncate what the user typed). Bounded and left alone: the numeric rflags in the FILTER2 trace and the in/exclude wording still describe a file-derived rule without quoting it, and the daemon's own FLOG line records the name it filtered -- that one goes to the operator's log, not the peer. Rules given AS arguments are still echoed in full -- that text is the user's own, and hiding it would only make ordinary typos harder to fix. Where a rule did come from a file, the diagnostic names the file and line instead, which is more useful anyway. Two things the location itself needed: fname can point into parse_merge_name()'s static buffer, which a merge rule inside the same file overwrites while we are still reading it, so a rule after a nested merge was blamed on the nested file -- keep our own copy. And a CRLF pair was counted as two line endings while word-split mode counted tokens rather than lines, so the number pointed at nothing; consume the LF of a CRLF (preserving the byte for the next rule if pushback ever fails), and report word-split sources without a line number. Not covered, deliberately: a rule's provenance is not serialized by send_filter_list(), so it does not survive to the far side. That is right -- only the client sends that list, and the server already knows the patterns the peer gave it.
WHAT IS RSYNC?
Rsync is a fast and extraordinarily versatile file copying tool for both remote and local files.
Rsync uses a delta-transfer algorithm which provides a very fast method for bringing remote files into sync. It does this by sending just the differences in the files across the link, without requiring that both sets of files are present at one of the ends of the link beforehand. At first glance this may seem impossible because the calculation of diffs between two files normally requires local access to both files.
A technical report describing the rsync algorithm is included with this package.
USAGE
Basically you use rsync just like scp, but rsync has many additional options. To get a complete list of supported options type:
rsync --help
See the manpage for more detailed information.
BUILDING AND INSTALLING
If you need to build rsync yourself, check out the INSTALL page for information on what libraries and packages you can use to get the maximum features in your build.
SETUP
Rsync normally uses ssh or rsh for communication with remote systems. It does not need to be setuid and requires no special privileges for installation. You must, however, have a working ssh or rsh system. Using ssh is recommended for its security features.
Alternatively, rsync can run in `daemon' mode, listening on a socket. This is generally used for public file distribution, although authentication and access control are available.
To install rsync, first run the "configure" script. This will create a Makefile and config.h appropriate for your system. Then type "make".
Note that on some systems you will have to force configure not to use gcc because gcc may not support some features (such as 64 bit file offsets) that your system may support. Set the environment variable CC to the name of your native compiler before running configure in this case.
Once built put a copy of rsync in your search path on the local and remote systems (or use "make install"). That's it!
RSYNC DAEMONS
Rsync can also talk to "rsync daemons" which can provide anonymous or authenticated rsync. See the rsyncd.conf(5) manpage for details on how to setup an rsync daemon. See the rsync(1) manpage for info on how to connect to an rsync daemon.
WEB SITE
For more information, visit the main rsync web site.
You'll find a FAQ list, downloads, resources, HTML versions of the manpages, etc.
MAILING LISTS
There is a mailing list for the discussion of rsync and its applications that is open to anyone to join. New releases are announced on this list, and there is also an announcement-only mailing list for those that want official announcements. See the mailing-list page for full details.
DISCORD
There is also an rsync Discord server for real-time chat about rsync and its development.
BUG REPORTS
The bug-tracking web page has full details on bug reporting.
That page contains links to the current bug list, and information on how to do a good job when reporting a bug. You might also like to try searching the Internet for the error message you've received, or looking in the mailing list archives.
To send a bug report, follow the instructions on the bug-tracking page of the web site.
Alternately, email your bug report to rsync@lists.samba.org.
For security issues please email details of the issue to rsync.project@gmail.com.
GIT REPOSITORY
If you want to get the very latest version of rsync direct from the source code repository, then you will need to use git. The git repo is hosted on GitHub and on Samba's site.
See the download page for full details on all the ways to grab the source.
COPYRIGHT
Rsync was originally written by Andrew Tridgell and Paul Mackerras. Many people from around the world have helped to maintain and improve it.
Special thanks go to Wayne Davison, who maintained rsync from 2004 to 2024.
Rsync may be used, modified and redistributed only under the terms of the GNU General Public License, found in the file COPYING in this distribution, or at the Free Software Foundation.