similar to: [Bug 12568] New: Integer overflow still affects xattrs.c

https://bugzilla.samba.org/show_bug.cgi?id=13113 Bug ID: 13113 Summary: receive_xattr heap overflow when prepending RSYNC_PREFIX Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned

The security.evm extended attribute is fully owned by the Linux kernel and cannot be directly written from userspace. Therefore, we can always skip it. --- xattrs.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/xattrs.c b/xattrs.c index b105392..3b72e61 100644 --- a/xattrs.c +++ b/xattrs.c @@ -255,6 +255,9 @@ static int rsync_xal_get(const char *fname,

https://bugzilla.samba.org/show_bug.cgi?id=13112 Bug ID: 13112 Summary: receive_xattr heap overread with non null terminated name and xattr filter Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

I recently found a bug in the xattrs patch, where it would apply the wrong xattrs to some files in a transfer. While looking at the code, I think I found another one (it sure looks wrong, but I haven't figured out how to demonstrate it yet). Anyway, here's the patch: The first hunk fixes the apparent bug. The second hunk fixes the demonstratable bug. I haven't (yet) looked to see

Hello, as of gcc v2.7.2.1, the noreturn attribute needs to be given *after* the prototype declaration and not before, but for gcc v3.x, things changed for this attribute again, since gcc v2.5.x did it the way, newer gcc versions prefer it... I've applied a small unified diff, fixing this stuff. THX for listening. CU Tom. (Thomas M.Ott) Germany -------------- next part -------------- ---

Hi. Two different hosts with 3.0.4 compiled from source, no patches. It seems fine except that -s causes protocol failures. See below. Local host is Sparc (Solaris 5.8), remote is Sparc (Solaris 5.10) or i686 Linux. Regards, Giuliano. userX@hostA$ /home/userX/tools/bin/rsync -v -v -v -v -v -n --rsync-path /home/userX/tools/bin/rsync -s . hostB: FILE_STRUCT_LEN=16, EXTRA_LEN=4 cmd=<NULL>

I think --partial might be a red herring here. It only applies to what happens when rsync is aborted in the middle of a file. What happens without -P? Also, it is worth trying with --inplace. On 12/30/18 5:32 PM, Heiko Schlittermann via rsync wrote: > Hi, > > I used --partial to transfer files from my local computer (rsync 3.1.2, > Debian) to a remote computer (rsync 3.1.1 WD

I would really appreciate help ! I did not have any reply to my two posts and I don't know what to do. I can't build 3.0.21a and I have to migrate 54 Solaris 2.5.1 servers from 2.2.8a to 3.0.x. I'm afraid we could not move to newer solaris versions before 12 or 18 months. Under is the problem description. Thank you for your help. Pierre --------- SOLARIS 7 --------- On Solaris 7

This draft patch adds support for transferring extended attributes with a new --xattr option. It ought to work on Linux with XFS or ext2/ext3 filesystems with the SGI/bestbits attribute system. It is partially working, but there seems to be some kind of hang bug while transferring the file list. I suspect it might be provoking a problem in io.c. You need to rerun autoconf, autoheader and

Hi, We upgraded from rsync 2.6.8 to 3.0.6, and ran into a problem with P (protect) rules coming in from filter files. The rule works if given on command line, but if given via . (merge), it no longer works. The effect is that files are not sent to the destination any more. I verified the problem still exists in 3.0.9pre2. I don't think this is bug 8309

I have a system running rsync in daemon mode, the version information: > rsync --version rsync version 2.6.8 protocol version 29 On another system I have: > authoritative# rsync --version rsync version 3.0.7 protocol version 30 I have the following problem when trying to fetch files from the system running the old daemon: # /usr/local/bin/rsync --protocol=29 -vvvvvvvv

I've written a patch to 2.6.8 which adds extended attribute support to rsync. This is not like the plethora of patches which try to separate osx meta-data into a special appledouble file (._filename). Instead, it builds on patches/xattr.patch and just adds support for the MacOS equivalent. The good news: 1. It works fine locally and to a remote mac 2. It also preserves the finder

Please forgive my digging up a two year old thread, but I've got the same problem, but the pointers there give no help. This is using versions 3.0.6 (server) and 3.0.7 (client). Unfortunately, I have to type the client stuff in by hand. ("Secured" laptop with highlighting & copying disabled.) Anyway: $ rsync -vvvvvv -a -e ssh --recursive gdoc rsync-acct at 99.99.99.99::doc

Hi, I used --partial to transfer files from my local computer (rsync 3.1.2, Debian) to a remote computer (rsync 3.1.1 WD MyPassport Storage device) The files get transferred, but after successful transfer, the files are not renamed from .<tmpfile> to <file>. Where to go next? Here is the verbose output after transferring an empty file heiko at blade:~/Pictures$ rsync

I've compiled rsync for my rooted Android (armeabi-v7a, 32-bit) device using these instructions: ``` clone_or_update rsync master git://git.samba.org/rsync.git cd rsync ./prepare-source ./configure \ --prefix=$INSTALL_ROOT/rsync \ --host=$AUTOCONF_PLATFORM \ CFLAGS="$CFLAGS -static" make -j8 && make install cd - ``` Best place for instructions to build I could find

Any concerns with the compiler warning on flist.c on a ia64 system running SLES10SP1? ~/rsync-3.0.0pre7> make gcc -std=gnu99 -g -O2 -DHAVE_CONFIG_H -Wall -W -o mkrounding -I. ./ mkrounding.c ./mkrounding >rounding.h Rounding file_extras in multiples of 2 (EXTRA_LEN=4, FILE_STRUCT_LEN=24) gcc -std=gnu99 -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -c flist.c -o flist.o /tmp/ccqjJwNs.s:

Hi all, I would like to implement rsync compatibility in my app. I'm building an ssh server and I want to support rsync. For example I execute this command: 1) rsync -avvvvvvvv -e "ssh -p 2022" /home/nicola/test.sh nicola at 127.0.0.1:/ and I get this exec command over ssh: 2) rsync --server -vvvvvvvvlogDtpre.iLsfxC . / I could simply execute the requested command and let it

This is a PoC patch for NFSv4/ZFS ACLs. The objective of the patch is that rsync --acls support NFSv4/ZFS ACLs without requiring a new command line option NFSv4 ACLs can't be represented using POSIX draft ACLs, if an NFSv4 ACL is present a separate POSIX draft ACL will not be present and there are new APIs to access NFSv4 ACLs. So we need to distinguish between NFSv4 ACLs and POSIX ACLs in

Setting up a new system backup (done several before and they all work fine). Windows 10 x64 (cygwin with rsync version 3.1.2) backing up to ubuntu server 16.04 (rsync 3.1.1). Run test.bat from command window (run as administrator) and it runs fine.Created scheduled task that runs test.bat and it hangs at "msg checking charset: UTF-8" until the timeout. I have upped the timeout to

Looking at http://rsync.samba.org/ftp/rsync/patches/fileflags.diff -- It looks like the changes from fileflags-fixes.diff patch were applied to the patch from http://rsync.samba.org/ftp/rsync/rsync-patches-3.0.0.tar.gz , but this entire chunk of the that original diff file was lost: > diff -up a/config.h.in b/config.h.in > --- a/config.h.in > +++ b/config.h.in > @@ -64,6 +64,9 @@