ftpd(1M) bug report and fix
Tom Haapanen
tom at mims-iris.waterloo.edu
Thu Jun 8 13:04:05 AEST 1989
I have been having a lot of trouble getting the 'ls' command working with
ftpd on our machine: a client calling in would get no output from an 'ls'
command at all. After getting no useful advice from tech support, I got
the new ftp & ftpd versions from uunet, and ported the ftpd to our 4D (we're
using 3.1C). Now, clients could use 'ls', but _not_ 'ls -l'. I spent a
great deal of time tracing through ftp and ftpd logic, trying to figure
out why an anonymous client (real users were OK) could not exec /bin/ls.
I renamed lc to ls, and that was fine. WHAT GIVES?
Eventually, after many attempts, replacing ls with a shell script in
~ftp/bin, and creating my own chroot test program, I discovered what
causes the problem: ls(1) uses a shared library! The library is in /lib,
which is no longer accessible once you do a chroot to ~ftp.
So, the fix to the problem is to create another directory containing
the shared library that ls needs:
~ftp:
d--x--x--x 2 root sys 512 Jun 7 15:28 lib
~ftp/lib:
-r-xr-xr-x 1 root sys 103268 Jun 7 15:28 libc_s
This is in addition to the files and directories as described in the
man pages for ftpd(1M) in our 3.1C documentation.
Didn't anyone test ftp/ftpd before it went out the door? Or did someone
just forget to update the manual?
\tom haapanen
tom at mims-iris.waterloo.edu
watmims research group
university of waterloo
"Now, you didn't really expect my views to agree with my employer's, did you?"
More information about the Comp.sys.sgi
mailing list