Bug 58874

Summary: New rsync package corrupts files during transfer.
Product: [Retired] Red Hat Linux Reporter: akopps
Component: rsyncAssignee: Bill Nottingham <notting>
Status: CLOSED ERRATA QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: dbarrett, gbailey, geoffrey, jss, matthias.saou, msterret, ralston, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-03-01 16:54:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
test script for rsync corruption bug none

Description akopps 2002-01-26 07:30:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901

Description of problem:
After upgrading to the new rsync package using rsync-2.4.6-8.i386.rpm, strange
things started happening. We run the following command on our machines daily:

rsync -a -H -v  /local/rh/7.2/install/files/ /
/local/rh is mounted over NFS from a RedHat Linux 6.2 server.

After installing the updated rsync package, it started printing the following
error after a copying certain file:

[root@zag root]# rsync -a -H -v  /local/rh/7.2/install/files/ /
building file list ... done
etc/
etc/rc.d/init.d/
etc/sendmail.cf
Warning: unexpected read size of 0 in map_ptr
Warning: unexpected read size of 0 in map_ptr
etc/
wrote 15643 bytes  read 438 bytes  32162.00 bytes/sec
total size is 1175178  speedup is 73.08

After running this, sendmail refused to start with an error:
[root@zag root]# /etc/init.d/sendmail start
Starting sendmail: 554 5.0.0 /etc/sendmail.cf: line 412: readcf: unknown option
name DaemME-encapsulated error messages?
Warning: OperatorChars is being redefined.
         It should only be set before ruleset definitions.
                                                           [FAILED]

I looked at the new /etc/sendmail.cf and it is not identical to the one from
where rsync copied it. Running diff reports:

[root@zag root]# diff /etc/sendmail.cf  /local/rh/7.2/install/files/etc/sendmail.cf
Binary files /etc/sendmail.cf and /local/rh/7.2/install/files/etc/sendmail.cf differ

Running diff -a shows shows -lots- of lines changed.

The files contain a different line count:
[root@zag root]# wc -l  /etc/sendmail.cf /local/rh/7.2/install/files/etc/sendmail.cf
   1964 /etc/sendmail.cf
   1490 /local/rh/7.2/install/files/etc/sendmail.cf

So, obviously, the new rsync corrupts our sendmail.cf and maybe
other files. I can provide more info if needed.

-akop


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Put the default RedHat 7.2 sendmail.cf file on a NFS mounted file
system, preferably from a vanilla RedHat 6.2 server, and make a simple
modification to it.
2.Use rsync to copy it to local disk -overwriting- the old sendmail.cf file (if
the old sendmail.cf is not present, the problem will not reproduce)
3. Compare the files.
	

Actual Results:  The new sendmail.cf is corrupted

Expected Results:  sendmail.cf should have been updated without causing breakage

Additional info:

Comment 1 Bill Nottingham 2002-01-27 05:48:20 UTC
Do you have a reliable case that reproduces this?

Comment 2 msterret 2002-01-27 07:59:01 UTC
This one's tricky to pin down for me.  Taking the rsync-2.4.6-unsigned.dif patch
out seems to fix it though.  I'm attaching my test script which shows the
problem on my box.

Comment 3 msterret 2002-01-27 08:00:15 UTC
Created attachment 43657 [details]
test script for rsync corruption bug

Comment 4 Bill Nottingham 2002-01-27 15:01:18 UTC
Hm, I can reproduce it with this test on the errata binary, but not on one I
build. Uh-oh.

Comment 5 msterret 2002-01-27 15:15:14 UTC
Arg!  I didn't think of trying that.  It works for me if I simply rebuild the
srpm as well.

Looks like a bad build somehow.  Not sure if it's important or not, but

grep 64 <strings of bad rsync> 

and

grep 64 < strings of good rsync>

shows that the bad one is missing the 64 bit io functions. (fopen64, glob64,
lseek64, readdir64)

Also, I don't see GLIBC_2.2 in the strings output of the bad rsync.

Comment 6 Bill Nottingham 2002-01-27 17:13:51 UTC
OK, I think I've figured out the build problem; please try:

http://people.redhat.com/notting/rsync-2.4.6-9.i386.rpm


Comment 7 msterret 2002-01-27 19:12:18 UTC
Works great for me - good job tracking this down over the weekend.
Can't wait to see the src rpm to see what fixed it.

Comment 8 Bill Nottingham 2002-01-27 19:26:58 UTC
Nothing. :( Solely a problem with the build machine.

Comment 9 akopps 2002-01-28 20:22:18 UTC
I just downloaded the new rsync package from
http://people.redhat.com/notting/rsync-2.4.6-9.i386.rpm
and it does work fine on my machine indeed.
Thanks for your hard work!

-akop



Comment 10 Jeremy Sanders 2002-01-29 12:34:19 UTC
I'm getting this error using the rsync just released as a security update. The
rsync in the RedHat 7.2 distribution did not have this problem. How did you
manage to release a broken RPM as a security update?




Comment 11 Jeremy Sanders 2002-01-29 12:47:00 UTC
Sorry. I see the the errata was published before this bug report. I assume
there's going to be an errata errata :-)


Comment 12 Bill Nottingham 2002-01-29 15:41:54 UTC
*** Bug 59013 has been marked as a duplicate of this bug. ***

Comment 13 Bill Nottingham 2002-01-29 15:42:10 UTC
*** Bug 58878 has been marked as a duplicate of this bug. ***

Comment 14 Bill Nottingham 2002-01-29 16:47:37 UTC
*** Bug 59026 has been marked as a duplicate of this bug. ***

Comment 15 Bill Crawford 2002-01-29 17:19:47 UTC
What's the real problem, then?  Is the Raw Hide package actually broken, or is
it purely the older version when used as the server side?


Comment 16 Bill Nottingham 2002-01-29 17:29:09 UTC
The problem is in the patch for the security problem. The fact that -9 works is
because building with LFS support manages to mask the problem on x86.

Comment 17 James Ralston 2002-01-29 21:26:21 UTC
Well, the http://people.redhat.com/notting/rsync-2.4.6-9.i386.rpm package does
indeed work for me.

Does either -8 or -9 actually fix the security problem?  If they do,
then I'll run -9 until the problem with the security patch can be
corrected and a new errata released; otherwise, I'll just drop back to
-5 (what shipped with RH7.2)...


Comment 18 Bill Nottingham 2002-01-29 21:33:18 UTC
Both packages fix the security problem (after all, that's why it was an errata
in the first place.)

Comment 19 T 2002-01-29 22:07:00 UTC
I got segfaults on redhat 7.2 with rsync 
ftp://updates.redhat.com/7.2/en/os/i386/rsync-2.4.6-8.i386.rpm
when rsync was trying to update a remote file


http://people.redhat.com/notting/rsync-2.4.6-9.i386.rpm
cured that problem.

Cheers
T.

Comment 20 Geoffrey D. Bennett 2002-01-30 08:25:21 UTC
If anyone's interested, the 2.4.6-8 is broken for me (ie. it corrupts files),
but http://people.redhat.com/notting/rsync-2.4.6-9.i386.rpm fixes the problem.

Surely if an updated update can't be released immediately, the broken rsync
should be removed or a notice about it released?  In my case at least, a bug
that randomly corrupts files is way worse than a security hole that can't be
exploited (since I don't provide rsync to the world).

Comment 21 Paul Johnson 2002-01-30 09:59:08 UTC
I would like to thank you for fixing the rsync problem, and curse you for the
fact that my mozilla bookmarks file was corrupted beyond recognition by rsync.

Comment 22 Need Real Name 2002-03-01 16:51:12 UTC
This problem still exists in rsync 2.4.6-10 under RedHat 7.0.  The transferred 
files get corrupted.  My command line is:

$ rsync -a -e ssh --rsync-path=/home/smith/.bin/rsync --cvs-exclude -v 
remotesite:mydir/\*RANKS .

which transfers a bunch of files named *RANKS to my local machine.

Comment 23 Need Real Name 2002-03-01 16:54:06 UTC
Forgot to mention in my previous comment: the remote rsync is 2.5.2 under 
Solaris.

$ ssh remotesite uname -a
SunOS uw 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-1

$ ssh remotesite rsync --version
rsync  version 2.5.2  protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others
<http://rsync.samba.org/>
Capabilities: 32-bit files, socketpairs, hard links, symlinks, batchfiles, no 
IPv6,
              32-bit system inums, 64-bit internal inums


Comment 24 Bill Nottingham 2002-03-01 17:25:23 UTC
Take the rsync-2.4.6-10 package, and extract the -moresignage patch. You most
likely need to apply that to the rsync on your Solaris box....