Path: utzoo!utgpu!watmath!maytag!watvlsi!watale!mims-iris.waterloo.edu!tom
From: tom@mims-iris.waterloo.edu (Tom Haapanen)
Newsgroups: comp.sys.sgi
Subject: ftpd(1M) bug report and fix
Message-ID: <3184@watale.waterloo.edu>
Date: 8 Jun 89 03:04:05 GMT
Sender: daemon@watale.waterloo.edu
Reply-To: tom@mims-iris.waterloo.edu (Tom Haapanen)
Distribution: world
Organization: WATMIMS Research Group, University of Waterloo
Lines: 34

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@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?"