Bug 460753 - rsync under fakechroot gives getpeername on fd0 failed: Invalid argument
rsync under fakechroot gives getpeername on fd0 failed: Invalid argument
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: fakechroot (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-30 19:35 EDT by Robin Norwood
Modified: 2008-10-13 20:49 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-07 05:47:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin Norwood 2008-08-30 19:35:58 EDT
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 03:13:16 EDT
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 14:06:36 EDT
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 17:40:37 EDT
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 12:52:12 EDT
ping?  Just checking to see if this fix will be in F10.
Comment 5 Martin Langhoff 2008-09-16 19:07:30 EDT
---------- Forwarded message ----------
From: Piotr Roszatycki <dexter@debian.org>
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@gmail.com>


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


---------- End Forwarded message ------
Comment 6 Martin Langhoff 2008-09-21 22:52:09 EDT
*bump* :-)
Comment 7 Fedora Update System 2008-10-05 12:38:31 EDT
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 12:38:35 EDT
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 05:47:28 EDT
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 05:48:45 EDT
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-13 20:49:00 EDT
Just a quick - THANKS!

Note You need to log in before you can comment on or make changes to this bug.