static linking, closed filehandles

[Joe Matarazzo]

Hi. I was hoping you could shed some light on a problem I recently had
involving running a statically linked binary under a chroot environment.

I compiled "ls" with static linking and installed it under an ftp
chroot'ed area.

When run as "chroot /home/ftp ls", I'd get the expected directory output
for /home/ftp. However, when I log in to my ftp server and try to run the
ls there, I get no output.

I used strace on the ftp daemon to watch the execv() call to /bin/ls, and
it turns out it was seg faulting b/c (/home/ftp/)/dev/null didn't exist.

I have a few questions as a result:

1) Is there something about closed filehandles that causes libc startup
code to attempt to map them to /dev/null? I would like to know why the
shell cmd "chroot /home/ftp ls" worked, but the ftp invocation didn't? One
explanation would be that the ftp code closes stdin before calling
execv(), and this in turn causes libc to do something with /dev/null on
startup.

2) I also tried dynamic linking with "ls" and put /home/ftp/lib out there
with the required libraries. Calling ls from ftp worked in this case. What
would be different about having a dynamically linked libc that would allow
"ls" to work even without /dev/null (which had caused the statically
linked version to fail)?

Thanks for your time,
Joe