Subject: [221] Re: [215] Re: [214] anonymous ftp and Fetch (a Mac ftp client)

From: [email-masked] (Anne Zanotti)
Date: Thu, 28 Jul 1994 16:25:28 +0930

>> 
>THANK GOD!  Someone else is having this problem too.  (No offense intended)

Ditto!!

>I have narrowed the problem down to this:  for some reason fetch needs the
>"dir" command which is the equivalent to "ls -al" to list the directories.
>I am assuming that you are running Solaris, because dir is a part of SunOS
>only.
>
>The way I have it figured, since normal users can use ls -al, and the anonymous
>ftp user cannot, there must be a library that the anonymous ftp user cannot
>find when trying to execute ls -al.  I have tried a bunch of libraries to
>~ftp/usr/lib but haven't found the one yet.  If collectively this mail 
>group can solve this problem it will indeed be an accomplishment, or at 
>least it will get the people in my office off my back about this. :-)
>

I am trying to get thid working on AIX 3.2.5.  I have tried mknod
~ftp/dev/zero c 3 12, as suggested by someone whose message I have thrown
out.   Thanks to whoever you are, but unfortunately this did not solve the
problem.  Also, AIX does not have the libraries that is has been suggested
be copied into ftp's directory structure.  So if anyone has any other
suggestions, I would be most grateful to hear them.

Thanks,

Anne

--
Anne Zanotti                    email:  [email-masked]
        Children aren't happy without something to ignore,
        And that's what parents were created for.               -- Ogden Nash

---

From: Charles Wiles <[email-masked]>
Date: Thu, 28 Jul 1994 13:19:13 +0100

Not being able to get dir or ls -l to work with anonymous ftp is probably
*the* most FAQ on this list.  As has been explained on numerous occasions
before, the problem relates to the fact that the ftpd executes a chroot()
system call to the anonymous ftp directory.  Since the ls command on most Unix
systems is dynamically linked, this means that all sorts of problems
occur (ie. files being inaccessible) which prevent ls from being run.  (Note
that the plain `ls' is a command built-in to the ftp server, so this is
unaffected by the chroot).

  To get ls to work with anonymous ftp, you have two choices:
    1. work out the pathnames of all the files required by your system to
       execute ls (eg. libraries, special device files, etc) and copy these
       files to their correct locations within the chroot'd environment
       (eg.  a /dev/zero would need to be created--with mknod NOT cp!--in
       ~ftp/dev/zero);
    2. get hold of/build a statically linked version of ls and place it in
       ~ftp/bin.

  #2 is the solution I adopted: it's a lot neater and easier than messing
around with creating the necessary sub-directories and files, which just
clutter up your anonymous ftp tree.

  Some manufacturers supply static copies of ls.  Ask them if they do.
Otherwise you could get hold of, say, the Free BSD ls source and compile it
yourself, making sure you use static linking.

  Good luck.
 ____________________________________________________________________________

  Charles Wiles, Systems Manager,               [email-masked]
  { Physics Practical Course (NeXT)                Tel. +44-(0)865 273450 }
  { Particle and Nuclear Physics (Sun/DEC)         Tel. +44-(0)865 273320 }
  Nuclear & Astrophysics Laboratory,
  Dept of Physics, University of Oxford,
  Keble Rd, OXFORD OX1 3RH, UK.                    Fax. +44-(0)865 273418
 ____________________________________________________________________________

---

From: "Randolph J. Herber" <[email-masked]>
Date: Thu, 28 Jul 1994 10:41:46 -0500

|Date: Wed, 27 Jul 1994 21:42:55 -0500 (CDT)
|From: Kris Lappala <[email-masked]>
|Subject: [215] Re: [214] anonymous ftp and Fetch (a Mac ftp client)
|To: [email-masked]

|> Here's a really wierd one (or at least I think it's really wierd).  I
|> can connect to my ftp server with Fetch and go in a a regular users
|> (real id and passwd), and everything is fine.  Go in as anonymous, and
|> directories don't list.  According to the Fetch logs, a connection for
|> /bin/ls was established, and according to wu-ftpd's logs (temporarily
|> running it in debug mode with -d), everything's okay.  But nothing
|> displays.  I can, however, download a file since I can do CWDs and
|> RETRs.

|> Anybody got a clue?

|> Thanks,
|> Rob

First, an attempt at humor.

USER 1: I wonder why the car doesn't go when I say gitte-up?
USER 2: That's funny, my horse goes when I push a key in and twist it!

You have to understand that the anonymous ftp environment is different
in a very important way.  And, that difference breaks many things if
you are not careful!

To provide a significant degree of file security, ftpd when running for
an anonymous user runs in a chroot(2) environment.  chroot declares that
a branch of the file tree is the entire file tree as far as any process
running in that environment is concerned and that all file names will be
resolved as if the root of the truncated file tree (the branch) were root
(/) itself.  In particular, this has a significant effect on symbolic links
because it changes the meaning of all absolute symbolic links (ones where
the target path starts with a /) and some relative symbolic links (ones
where the target path does not start with a /), namely those that attempt
to back up beyond the base of the branch using ``too many'' .. references.
It also affects the interpretation of the filenames embedded or implied
in executables with dynamically loaded shared libraries.  Those filenames
are subjected to a similar change in interpretation.  Those libraries must
be copied to the equivalent position under the base of the branch to the
position that they reside in relative to the system root --- symbolic links
can __not__ be used for this purpose --- these must be copies or hard links
if hard links are possible (the anonymous ftp branch base must be in the
same filesystem as where the libraries are currently resident)!

There are system utility programs on most systems that will list the embedded
or implied shared library pathnames used by a particular program.  Determine
the union of those libraries used by the various programs in the anonymous
ftp bin directory and copy those libraries to the proper location.

Computers and computer systems are much easier to use when you understand
how they actually work.

|THANK GOD!  Someone else is having this problem too.  (No offense intended)
|I have narrowed the problem down to this:  for some reason fetch needs the
|"dir" command which is the equivalent to "ls -al" to list the directories.
|I am assuming that you are running Solaris, because dir is a part of SunOS only.

|The way I have it figured, since normal users can use ls -al, and the anonymous
|ftp user cannot, there must be a library that the anonymous ftp user cannot
|find when trying to execute ls -al.  I have tried a bunch of libraries to
|~ftp/usr/lib but haven't found the one yet.  If collectively this mail 
|group can solve this problem it will indeed be an accomplishment, or at 
|least it will get the people in my office off my back about this. :-)

I believe you are correct.  See above.

|Kris Lappala
[email-masked]

Randolph J. Herber, [email-masked], +1 708 840 2966, CD/HQ
(Speaking for myself and not for US, US DOE, FNAL nor URA.)
(Product, trade, or service marks herein belong to their respective owners.)

---

From: "Randolph J. Herber" <[email-masked]>
Date: Thu, 28 Jul 1994 10:57:42 -0500

|Date: Wed, 27 Jul 1994 23:05:41 -0400
|From: "That Whispering Wolf..." <[email-masked]>
|Subject: [216] Re: [215] Re: [214] anonymous ftp and Fetch (a Mac ftp client)

I am not saying that your data is incorrect for your environment.
I am saying that your data is incorrect when applied across all operating
system environments that wu-ftpd may be running in.

Please identify which environment you are refering to when you make
statements like these.

|Even though this one has been answered a LOT of times, I'm sending a note 
|about it because there's one problem that many people fail to mention as a 
|possible problem with this.

|First, you must have an ~ftp/usr/lib directory -- Mine looks like this:

|dr-xr-xr-x  2 ftp           512 Apr 15 11:30 .
|d--x--x--x  3 root          512 Mar 15 21:43 ..
|-r-xr-xr-x  1 root        49152 Mar 15 21:43 ld.so
|-r-xr-xr-x  1 root         7996 Mar 15 21:43 libc.sa.1.8
|-r-xr-xr-x  1 root         8478 Mar 15 21:43 libc.sa.1.8.1
|-r-xr-xr-x  1 root       516096 Mar 15 21:43 libc.so.1.8
|-r-xr-xr-x  1 root       548864 Mar 15 21:43 libc.so.1.8.1
|-r-xr-xr-x  1 root        24576 Mar 15 21:43 libdl.so.1.0

My shared libraries have different names and reside in different
directories.  Furthermore, my /bin/ls is statically linked (i.e.,
does not use shared libraries).

|I had this much (plus ~ftp/bin/ls, of course) installed on a system at one
|point in time, and ls STILL did not work. After about two hours of angsting,
|I found the problem.

|ls -also- requres ~ftp/dev/zero. On the system I couldn't get to work, I'd 
|simply tar'd up my config here and untar'd it there, and for some reason the
|device node didn't come across propperly.

ls on my system does __not__ require /dev/zero.  But, it appears to require
/dev/log and /dev/console.

|My /dev directory looks like this:

|d--x--x--x  2 root          512 Mar 15 21:46 .
|drwxr-xr-x  8 root          512 Jul 26 16:53 ..
|crw-rw-rw-  1 ftp        3,  12 Apr 15 10:57 zero

|You can make the zero node with the command:

|mknod ~ftp/dev/zero c 3 12

Maybe you can make a proper ~ftp/dev/zero for your environment this way.  In
another environment, this might be a tape drive!

|Once that is all done (bin directory, /usr/lib directory, and /dev directory),
|I'll bet it'll work.

|									-WW

My environment is SGI IRIX 4.0.5H.