mirror of
https://github.com/RsyncProject/rsync.git
synced 2026-06-07 21:58:06 -04:00
5972ebdaf8
The symlink-race hardening routed the receiver's basis open through secure_relative_open(), which rejects any '..' -- so a sibling --link-dest=../01 on a use-chroot=no daemon was silently ignored and every file re-transferred (#915/#928, a regression from 3.4.1). Narrow the confinement to the sanitizing daemon (am_daemon && !am_chrooted) and re-anchor it at the module root, the real trust boundary: secure_relative_open() prefixes the cwd's module-relative path (from rsync's logical curr_dir[], a guaranteed lexical prefix of module_dir) and resolves beneath module_dir, so RESOLVE_BENEATH permits an in-module '..' climb while still rejecting one that escapes the module. secure_basis_open() opens with a bare do_open() in the non-sanitizing cases. t_stub.c gains weak curr_dir[]/curr_dir_len for the helpers (via #pragma weak on non-GNU compilers, where rsync.h erases __attribute__). Two tests: link-dest-relative-basis asserts the in-module '..' is honoured; link-dest-module-escape asserts a --link-dest=../../OUTSIDE climb that leaves the module is refused (not hard-linked to an outside file). See upstream PR #930.
automatic testsuite for rsync -*- text -*- We're trying to develop some more substantial tests to prevent rsync regressions. Ideally, all code changes or bug reports would come with an appropriate test suite. You can run these tests by typing "make check" in the build directory. The tests will run using the rsync binary in the build directory, so you do not need to do "make install" first. Indeed, you probably should not install rsync before running the tests. If you instead type "make installcheck" then the suite will test the rsync binary from its installed location (e.g. /usr/local/bin/rsync). You can use this to test a distribution build, or perhaps to run a new test suite against an old version of rsync. Note that in accordance with the GNU Standards, installcheck does not look for rsync on the path. If the tests pass, you should see a report to that effect. Some tests require being root or some other precondition, and so will normally not be checked -- look at the test scripts for more information. If the tests fail, you will see rather more output. The scratch directory will remain in the build directory. It would be useful if you could include the log messages when reporting a failure. These tests also run automatically on the build farm, and you can see the results on http://build.samba.org/.