Subject: Re: [PATCH] built-in 'ls'

From: [email-masked] (William L. Sebok)
Date: Mon, 16 Dec 1996 16:00:25 -0500 (EST)

Peter Norton <[email-masked]> wrote:
> I'm sure someone will correct me if I'm wrong, but isn't it possible to
> put copies, or hard links to your /lib/libc*.so.* into your ~ftp/lib?

Jeremy Chadwick <[email-masked]> replied:
> 	Of course.
> 
> 	But when you have 400 to 800 users who want this feature, so
> 	customers can pull their newest file distributions, you start
> 	to notice most of your disk consists of libraries for anonymous
> 	FTPs. A static 'ls' binary is much more suiting for what we
> 	need :-)

You just need one copy of the libs per filesystem.  The libs for all of the
users who live on the same filesystem can be hardlinked together.

Bill Sebok      Computer Software Manager, Univ. of Maryland, Astronomy
	Internet: [email-masked]	URL: http://www.astro.umd.edu/~wls/

---

From: Ben Mehlman <[email-masked]>
Date: Mon, 16 Dec 1996 16:33:40 -0500 (EST)

Hi.  I'm new to the list (just sub'd this morning), but I think I get the
gist of this thread.  I have a setup here where using an external ls is not
feasible.  I solved the problem very simply, by using the ls code from GNU
fileutils.

It's two source changes- one to ls.c changing main() to ls_main(), and one
to ftpd_popen(), to call ls_main() instead of exec(), if the program to be
executed is ls.  I build the fileutils support libraries as usual, then link
with them and with the two ls-specific objects.  It's fat but it's
compatible.

-Ben Mehlman

---------------------------------------------------------------------------
Ben Mehlman                                   Vladimir: Well?  Shall we go?
Prodigy Services Company                      Estragon: Yes, let's go.
[email-masked]                                   (They do not move).

---

From: Yoshi <[email-masked]>
Date: Mon, 16 Dec 1996 13:57:54 -0800 (PST)

> In a previous message, Yoshi said:
> No read sentence incomprehensible i can.

	?!?!

> The amount of users using your system has nothing (directly) to do
> with the amount of space being taken up by ~ftp/{dev, bin, lib}. Nor
> does the age of the file distribution they are all downloading like
> lemmings.
> 
> Or maybe I'm not reading the above correctly.

	This seems to be the case.

	My statement above is solely in response to someone recommending
	I copy all libs used by Solaris ls (via ldd) to ~ftp/lib.

	If I have 400-800 clients who want to make use of this feature
	(using 'guestgroup' in /etc/ftpaccess), copying libraries begins
	to take up a significant amount of disk.

	It was then recommended by Bill Sebok that I could use hard-links
	which works, but I personally took the static ls approach -- and
	so far, everything has been grand.

> In any case, let me throw imho.
> 
> You can accomplish getting ls to work in any of a number of ways:
> 
> 1) Put a shared ls into ~ftp/bin along with all the shared libraries
> it's linked against into ~ftp/lib (don't forget the dynamic linker).

	For 400-800 accounts? I think not.

> 2) Build a static ls and put it into ~ftp/bin.
> 
> 3) Hard code ls into ftpd.
> 
> Of course, it's preferable to have 2 instead of 1, and anyone who has
> enough clue to copy all of the dynamic ftpd's dependencies should have
> enough clue to build a static ls, so there is almost no reason to use
> a dynamic ls.

	And this was my point in the very beginning, or atleast how I
	intended it to be ;-)

> So the question is, 2 or 3?
> 
> My main objection to 3 is that we're reinventing the wheel
> here. Moreover, there's no reason to do so. If you need to run an ftp
> server under Solaris and can't figure out how to make it work you
> should get NT.

	Implementing an option under wu-ftpd to support the ability
	of compiling in GNU ls (from fileutils) is a good idea -- GNU
	re-created the wheel, there's no need for us to write the
	sourcecode when minor adjustments can be made to wu-ftpd to
	actually support linking in GNU fileutils's ls.

> Then we get into other issues. Like the memory footprint of a bloated
> ftpd with ls and all the trimmings in it. When you have 800 users
> clamoring for the newest version of netscape this becomes very
> important.
> 
> There are security issues at foot too, the ls /has/ to be run within
> the chroot() (although you'd have to go out of your way to do
> otherwise) and it has to run without permissions (also should be a no
> brainer). Undoubtedly there are some things I've forgotten as well.

	Right, and this all boils down to the fact that the best solution
	right now is to compile a static version of ls -- which I have
	done, and all is well. Hurray. :-)

	(I honestly didn't expect this subject to become such a large
	discussed thread, but it's apparent this is a concern to all
	users of wu-ftpd, so we might as well approach it, if it hasn't
	be approached prior to now).

--
| Jeremy Chadwick                                        [email-masked] |
| System/Network/Security Administrator                        541-330-0435 |
| http://yoshi.parodius.com                                                 |

---

From: "Karl O. Pinc" <[email-masked]>
Date: Thu, 26 Dec 1996 11:10:08 -0600

Hannu Laurila <[email-masked]> wrote:
>On Mon, 16 Dec 1996, Karl O. Pinc wrote:
>
>> Why not?  If you use hard links you don't take up any more disk space (just
>> one copy per file system is required.)  So, what's wrong with this method?
>
>Less files, less administration, easier upgrades, simpler setups --> less
>security risks

Trouble is, it dosen't make things substantially simpler.  You still have
to have (minimally) /etc and have to have /bin and /lib if you want to
support the fancy tar and zip suff.  And the
security/reliability/complexity problems are only pushed into the code
where they are harder to work with.

I'd opt for a configuration utility (script).  You give it a directory and
it makes the directory anonymous ftp-able.  Various options to
allow/disallow different bin utilities (would remove stuff from bin as well
as add).  An option to supply a directory to be used as a "template".  An
option to hardlink to the template directory's leaf nodes.  An option to
"update" to make the target directory conform to a template or set of
command line specifications.

Is it do-able to have a "allow ls" option that knows what libraries ls
requires across different platforms?  Or would each platform have to have
library info hardcoded?

On a slightly different note:  I'd opt for _removing_ the class and
guestgroup stuff.  tcpwrappers does a more through job of setting up
"classes".  Pluggable components are better -- more widely used, more
options, less bugs, etc.  You'd need a) a command line option to specify a
configuration file (I have a patch at ftp://ftp.meme.com/software/) b) a
configuration file directive to force a directory to chroot to as with
anonynmous ftp.  I haven't thought this through. You'd probably want to
keep whatever keeps track of login names and just get rid of the network
layer class making.  You could probably get rid of some other stuff as well.

Karl

May the Legos (TM) always be swept from your path in the night.