--daemon doesn't respect --address?

Ali Polatel alip at exherbo.org
Sat Jan 23 02:00:00 MST 2010


Benjamin R. Haskell yazmış:
> On Fri, 22 Jan 2010, Ali Polatel wrote:
> 
> > I've noticed a weirdness in rsync.
> > Let me explain it briefly with an example.
> > Below is a test script:
> > 
> > #!/bin/sh
> > 
> > cat >rsyncd.conf <<EOF
> > address = localhost
> > use chroot = no
> > hosts allow = localhost
> > [from]
> >     path = /tmp/from
> >     read only = yes
> >     comment = r/o
> > EOF
> > 
> > RSYNC_CONNECT_PROG="rsync --address=localhost --config=rsyncd.conf --daemon" \
> > rsync -av --address=localhost rsync://localhost/from to
> > 
> > Looking at the code the daemon should bind to localhost not 0.0.0.0.
> > But strace shows the opposite:
> > alip at harikalardiyari> strace -fe bind ./test.sh
> > ...
> > [pid 7279] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> > ...
> > 
> > Is this a bug or am I misunderstanding something?
> 
> From the code, the bind you're seeing is from sock_exec in options.c, 
> which has the following comment preceding it:
> 
> /**
>  * Run a program on a local tcp socket, so that we can talk to it's
>  * stdin and stdout.  This is used to fake a connection to a daemon
>  * for testing -- not for the normal case of running SSH.
>  *
>  * @return a socket which is attached to a subprocess running
>  * "prog". stdin and stdout are attached. stderr is left attached to
>  * the original stderr
>  **/
> int sock_exec(const char *prog)
> 
> 
> It gets called essentially as: sock_exec(getenv("RSYNC_CONNECT_PROG"))
> 
> When running the daemon standalone, I see the appropriate behavior.  And 
> with various versions of your command, I'm unable to get any reasonable 
> output.  (Something with permissions on '.', even though I chmod'ed 777 
> on the temp dir.)  And, I see that bind() occurring before I see the 
> execve() of the RSYNC_CONNECT_PROG (strace -fe trace=bind,process).  So, 
> that bind() is unrelated to the daemon itself (I think).

(resending to the mailing list, as first mail didn't make it to the list.)

Running rsync under gdb shows there's just one bind():

(gdb) break bind
Breakpoint 1 at 0x402dd0
(gdb) run
Starting program: /usr/bin/rsync -av --address=localhost rsync://localhost/from to

Breakpoint 1, bind () at ../sysdeps/unix/syscall-template.S:82
82	../sysdeps/unix/syscall-template.S: Böyle bir dosya ya da dizin yok.
	in ../sysdeps/unix/syscall-template.S
Current language:  auto
The current source language is "auto; currently asm".
(gdb) bt
#0  bind () at ../sysdeps/unix/syscall-template.S:82
#1  0x000000000042b526 in socketpair_tcp (prog=0x7fffffffdd47 "rsync --address=localhost --config=rsyncd.conf --daemon")
    at socket.c:765
#2  sock_exec (prog=0x7fffffffdd47 "rsync --address=localhost --config=rsyncd.conf --daemon") at socket.c:829
#3  0x0000000000431614 in start_socket_client (host=0x66c430 "localhost", remote_argc=1, remote_argv=0x66c240, argc=1, 
    argv=0x66c248) at clientserver.c:121
#4  0x000000000041c172 in start_client (argc=2, argv=0x66c240) at main.c:1233
#5  main (argc=2, argv=0x66c240) at main.c:1501

socket.c:765 looks like:

...
763> sock2.sin_family = PF_INET;
764>
765> bind(listener, (struct sockaddr *)&sock2, sizeof sock2);
...

Shouldn't that bind() prepended by "sock2.sin_addr.s_addr = htonl(INADDR_LOOPBACK);"?

> Best,
> Ben

-- 
Regards,
Ali Polatel


More information about the rsync mailing list