search for: sanitize_paths

Hiya. While merging the 2.6.0 changes into our modified version of rsync, I noticed the following bit of code in 2.6.0's options.c: extern int sanitize_paths; if (sanitize_paths) sanitize_path(strdup(files_from), NULL); filesfrom_fd = open(files_from, O_RDONLY|O_BINARY); Since sanitize_path modifies its first argument in place, the path that open() gets there hasn't been sanitized, which could be a security issue --...

https://bugzilla.samba.org/show_bug.cgi?id=13105 Bug ID: 13105 Summary: 1byte heap overflow in sanitize_path Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

When using the rsync server without chroot, the --link-dest and --compare-dest options are almost useless. This is because sanitize_paths is called on the link-dest directory, stripping out leading dots and slashes. Thus, the only possiblitiy for a link-dest directory is under the target directory, which is generally not useful. There doesn't seem to be an easy fix. sanitize_paths is applied indiscriminately to all arguments,...

Hopefully the email to the announce list will show up soon. Until then, you can get a jump on the rest by checking out the rsync home page to read the announcement: http://rsync.samba.org/ It includes a security note about a fix that affects read/write daemons that are not using chroot. If that includes you, you should look into upgrading (or maybe enabling chroot on an older rsync).

Hi NG, I want to do incremental backups to a remote server running rsyncd (because daemonless transfer via ssh often hangs!). In contrast to transfer via ssh (without remote rsyncd) this doesn't seem possible, or do I miss something? Imagine I want to incrementally backup `mydir' to the backup space `backup' on e remote server `alpha' running an rsync daemon. rsyncd on

SUMMARY There is a path-sanitizing bug that affects daemon mode in all recent rsync versions (including 2.6.2) but only if chroot is disabled. It does NOT affect the normal send/receive filenames that specify what files should be transferred (this is because these names happen to get sanitized twice, and thus the second call removes any lingering leading slash(es) that the first call left

.../foo/bar rsync directory host:/foo/bar/ Here's a patch which, at least, doesn't seem to do any harm on Solaris or Linux and fixes the problem on HP. Cheers, Mark --- util.c.OLD Tue Jan 29 15:25:08 2002 +++ util.c Tue Jan 29 15:30:03 2002 @@ -542,6 +542,7 @@ return; #else extern int sanitize_paths; + int trailing_slash = 0; glob_t globbuf; int i; @@ -559,10 +560,25 @@ globfree(&globbuf); return; } - for (i=0; i<(maxargs - (*argc)) && i < (int) globbuf.gl_pathc;i++) { + + /* remember pattern's trailing '/' (HP/UX glob(3) leaves it off matches) */ +...

...n running an rsync daemon, absolute sym-links are not created correctly on the daemon end; the leading 'slash' is stripped off. To 'fix' this behavior, the following 3 changes can be made (to version 2.5.5): flist.c:63 add: extern int am_daemon; flist.c:538 (was 537) modify: if (sanitize_paths && !am_daemon) { config.h:316 modify: #define RSYNC_VERSION "2.5.6" I'm incredibly busy (aren't we all....) and don't currently have time to research how to do an 'official' patch, or how to submit official fixes, or even figure out if this 'fix' has...

Hi, Here is the problem (syscall.c, function do_open) on NT, Win2K, WinXP, with stripped "/" for UNC path convention, detected in release 2.5.5, 2.5.6: int do_open(char *pathname, int flags, mode_t mode) { if (flags != O_RDONLY) { if (dry_run) return -1; CHECK_RO } #ifdef O_BINARY /* for Windows */ flags |= O_BINARY; #endif /* some systems can't handle a double / */

...; and it appears to work fine. Although I'm pretty certain of the fix for daemon rsync, I am unsure if my fix affects non-daemon operation..... At any rate, for your consideration, here is the description of the fix: flist.c:63 add: extern int am_daemon; flist.c:531 (was 530) modify: if (sanitize_paths && !am_daemon) { ======================= Kirby Bakken ESW Build Architect Rochester, MN email: kirbyb@us.ibm.com ezpage:kirbyb 507-253-4549 / Tie: 553-4549 Fax: 507-253-3495 ......one more straw can't possibly matter....

Dear collegaues, please evaluate the patch attached, which allow to use both --detect-renamed and --fileflags extra features. This is meta-patch which sould be applied to detect-renamed. fileflags patch should be applied first, following by the modified detect-renamed patch. It is included in current FreeBSD port, but it seems it would be much more useful to be supported by samba

https://bugzilla.samba.org/show_bug.cgi?id=12817 Bug ID: 12817 Summary: [PATCH] Allow daemon itself to chroot Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter:

..._only) argstr[x++] = 'u'; if (dry_run) --- rsync-2.6.1/util.c.bak 2004-04-23 01:17:15.000000000 +0300 +++ rsync-2.6.1/util.c 2004-04-27 19:15:29.000000000 +0300 @@ -29,6 +29,7 @@ extern int verbose; extern struct exclude_list_struct server_exclude_list; +extern int do_fsync; int sanitize_paths = 0; @@ -281,8 +282,22 @@ int copy_file(char *source, char *dest, } } - close(ifd); - close(ofd); + if (close(ifd) != 0) { + rprintf(FINFO, "close failed on %s: %s\n", + source, strerror(errno)); + } + + if (do_fsync && (fsync(ofd) != 0)) { + rprintf(FERROR, "fs...

..., 0, 0, 0 }, @@ -656,20 +661,26 @@ XFLG_DEF_INCLUDE); break; + case OPT_IGNORE: + add_filter(&filter_list, poptGetOptArg(pc), + XFLG_DEF_IGNORE); + break; + case OPT_EXCLUDE_FROM: case OPT_INCLUDE_FROM: + case OPT_IGNORE_FROM: arg = poptGetOptArg(pc); if (sanitize_paths) arg = sanitize_path(NULL, arg, NULL, 0); if (server_filter_list.head) { char *cp = (char *)arg; clean_fname(cp, 1); - if (check_filter(&server_filter_list, cp, 0) < 0) + if (check_filter(&server_filter_list, cp, 0) == M_EXCLUDE) goto options_rejected;...

https://bugzilla.samba.org/show_bug.cgi?id=4263 Summary: Symlinks gets corruped when rsyncd is used to 'put' the symlink. Product: rsync Version: 2.6.8 Platform: Sparc OS/Version: Solaris Status: NEW Severity: critical Priority: P3 Component: core AssignedTo:

..., MAXPATHLEN); + flags = base_flags; @@ -563,6 +567,9 @@ void receive_file_entry(struct file_stru strlcpy(lastname, thisname, MAXPATHLEN); + if (!am_server) /* fname conversion always done on client */ + convert_fname(thisname, lastname, MAXPATHLEN); + clean_fname(thisname); if (sanitize_paths) @@ -1043,6 +1050,9 @@ struct file_list *send_file_list(int f, start_write = stats.total_written; + if (!am_server) + init_fname_convert(); + flist = flist_new(f == -1 ? WITHOUT_HLINK : WITH_HLINK, "send_file_list"); @@ -1217,6 +1227,9 @@ struct file_list *send_file_list...

...t.c --- rsync-2.6.6/flist.c 2005-07-07 21:49:14.000000000 +0200 +++ rsync-2.6.6_patch/flist.c 2006-01-07 14:04:38.000000000 +0100 @@ -54,6 +54,7 @@ extern int implied_dirs; extern int copy_links; extern int copy_unsafe_links; +extern int remote_protocol; extern int protocol_version; extern int sanitize_paths; extern int orig_umask; @@ -314,6 +315,7 @@ { unsigned short flags; static time_t modtime; + static time_t acctime; static mode_t mode; static int64 dev; static dev_t rdev; @@ -329,7 +331,7 @@ if (!file) { write_byte(f, 0); - modtime = 0, mode = 0; + modtime = 0, acctime = 0, m...

...iled\n", lp_path(i)); ! io_printf(fd,"@ERROR: chdir failed\n"); return -1; } } else { if (!push_dir(lp_path(i), 0)) { rprintf(FERROR,"chdir %s failed\n", lp_path(i)); ! io_printf(fd,"@ERROR: chdir failed\n"); return -1; } sanitize_paths = 1; --- 254,273 ---- if (use_chroot) { if (chroot(lp_path(i))) { rprintf(FERROR,"chroot %s failed\n", lp_path(i)); ! io_printf(f_out,"@ERROR: chroot failed\n"); return -1; } if (!push_dir("/", 0)) { rprintf(FERROR,"chdir %s fai...

Hiya, I can see it's a regular subject on this list. I, like others wanted to use rsync to synchronise two block devices (as it happens one lvm volume and one nbd device served by qemu-img on a remote host from a qcow2 disk image so that I can keep the old versions) As I couldn't find any report of it being done successfully, I'm just sharing my findings as it might benefit others.

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.