possible bash2 bug

[Tom Allen]

I'm not sure this is a bug, but its definitely different than expected 
behavior.

I have an ssh2 key on SERVER, as such:
command="/usr/bin/nice -n 19 /usr/local/bin/rsync --server 
--one-file-system --daemon --config /etc/rsyncd.conf 
.",from="fs1.theaimsgroup.com" ssh-dss BIGFATKEYHERE root@tallen1

SERVER has /etc/rsyncd.conf as such:

uid = nobody
gid = nobody
use chroot = no
max connections = 1
syslog facility = local5
pid file = /var/run/rsyncd.pid
[slash]
       list = no
       path = /
       read only = yes
       hosts allow = 0.0.0.0
       use chroot = yes
       max connections = 1
       exclude = /vol/ /proc/
       uid = root
       gid = root

Note the hosts allow = 0.0.0.0 .

Using the private key from CLIENT, if I try to ssh/rsync:
If /etc/passwd has root's shell set to bash2, rsyncing works.
If /etc/passwd has root's shell set to bash1, or ash, or zsh, or tcsh, 
or csh, etc., rsyncing fails.

When it works, it shows that I was authorized from 0.0.0.0.  When it 
fails, it says access denied from xx.xx.xx.xx with the full ip of CLIENT.

This is duplicatable with every version of bash I could find, linux 
2.4.22 smp kernel + grsec patches, dual PIII.  rsync is versions 2.5.6, 
2.5.7, and an older version I forgot the number of. ssh is 
OpenSsh_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.6k. gcc is 
egcs-2.91.66 .

The current bash on the box is 2.04.0 .

If I can provide any additional data, or if you could point me to a 
better forum, or an explanation (it appears getpeername() call from 
rsync returns 0.0.0.0 if the shell is bash 2) please email me.  This has 
sparked a huge argument in my office over which is "correct".


--Tom
tom@nonserviam.net