Bug 460753

Summary:	rsync under fakechroot gives getpeername on fd0 failed: Invalid argument
Product:	[Fedora] Fedora	Reporter:	Robin Norwood <robin.norwood>
Component:	fakechroot	Assignee:	Axel Thimm <axel.thimm>
Status:	CLOSED NEXTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	martin
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-10-07 09:47:31 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:

Description Robin Norwood 2008-08-30 23:35:58 UTC

Description of problem:
Original report can be found here:

https://www.redhat.com/archives/fedora-olpc-list/2008-August/msg00101.html

I've reproduced this with a stock fedora, not including xs-rsync or other OLPC packages.

running rsync against localhost gives:

$ rsync rsync://localhost/
rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(794) [receiver=3.0.3]

While in /var/log/messages the following appears:

Aug 30 19:20:57 localhost xinetd[29293]: START: rsync pid=29348 from=::ffff:127.0.0.1
Aug 30 19:20:57 localhost rsyncd[29348]: rsync: getpeername on fd0 failed: Invalid argument (22)
Aug 30 19:20:57 localhost rsyncd[29348]: rsync error: error in socket IO (code 10) at clientname.c(168) [receiver=3.0.3]
Aug 30 19:20:57 localhost xinetd[29293]: EXIT: rsync status=10 pid=29348 duration=0(sec)

This happens when rsync is run under fakechroot, but not when it is run normally.

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

fakechroot-2.8-13.fc9.i386
rsync-3.0.3-0.fc9.i386
xinetd-2.3.14-20.fc9.i386

How reproducible:

always

Steps to Reproduce:
1. Set up rsync like so:

/etc/xinetd.d/rsync: http://rnorwood.fedorapeople.org/rsync
/etc/rsyncd.conf: http://rnorwood.fedorapeople.org/rsyncd.conf

2. Verify that rsync works fine:

$ sudo /sbin/service xinetd restart
Stopping xinetd:                                           [  OK  ]
Starting xinetd:                                           [  OK  ]
$ rsync rsync://localhost/
share          	share drive

3. Change /etc/xinetd.d/rsync so that rsync runs under fakechroot:
http://rnorwood.fedorapeople.org/rsync-fakechroot
  
Actual results:

$ rsync rsync://localhost/
rsync: read error: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(794) [receiver=3.0.3]


Expected results:

$ rsync rsync://localhost/
share          	share drive

Additional info:

I notice in rsync's configure.sh there is a stanza that seems to be changing the args to getpeername based upon the platform.  Maybe the args from fakechroot do not match.

Also, to test this, I completely removed the getpeername function from rsync and rebuilt it, and the problem went away.  The patch I used: http://rnorwood.fedorapeople.org/robin-fakechroot.patch

Comment 1 Axel Thimm 2008-08-31 07:13:16 UTC

Thanks for the debugging!

I think the next steps are to reenable the getpeername wrapper in fakechroot and see which part of the code makes it bail out. But I think I already see the bug, newnamelen is never initialized. It should look like

     char *fakechroot_path, *fakechroot_ptr, fakechroot_buf[FAKECHROOT_MAXPATH];
 
     if (next_getpeername == NULL) fakechroot_init();
-    memset(&newname, 0, sizeof(struct sockaddr_un));
+    newnamelen = sizeof(struct sockaddr_un);
+    memset(&newname, 0, newnamelen);
     status = next_getpeername(s, (struct sockaddr *)&newname, &newnamelen);
     if (status != 0) {
         return status;
     }

Can you try the above and see if it fixes it? Thanks!

Comment 2 Robin Norwood 2008-08-31 18:06:36 UTC

yes, your patch fixes the issue for me, thanks!

Also, getsockname() follows the same pattern, and looks like it could use a similar patch as well.

Comment 3 Axel Thimm 2008-08-31 21:40:37 UTC

Thanks for testing and reporting!

I'll wait a day or two for upstream's comments and will commit the fixes. 

Currently the updates are stalled anyway. :(

Comment 4 Robin Norwood 2008-09-14 16:52:12 UTC

ping?  Just checking to see if this fix will be in F10.

Comment 5 Martin Langhoff 2008-09-16 23:07:30 UTC

---------- Forwarded message ----------
From: Piotr Roszatycki <dexter>
Date: Fri, Sep 12, 2008 at 8:20 AM
Subject: Re: [Server-devel] RFH - xs-rsync on F9 fails with an odd error
To: Martin Langhoff <martin.langhoff>


Thanks for patch. I think I'll apply it to new fakechroot's release.


---------- End Forwarded message ------

Comment 6 Martin Langhoff 2008-09-22 02:52:09 UTC

*bump* :-)

Comment 7 Fedora Update System 2008-10-05 16:38:31 UTC

fakechroot-2.8-15.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/fakechroot-2.8-15.fc9

Comment 8 Fedora Update System 2008-10-05 16:38:35 UTC

fakechroot-2.8-15.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/fakechroot-2.8-15.fc8

Comment 9 Fedora Update System 2008-10-07 09:47:28 UTC

fakechroot-2.8-15.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2008-10-07 09:48:45 UTC

fakechroot-2.8-15.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Martin Langhoff 2008-10-14 00:49:00 UTC

Just a quick - THANKS!