Re: a point is being missed

[Doug.Hughes () Eng Auburn EDU (Doug Hughes)]

> The REAL value of shared libs IMHO is the fact that you can patch a bug or add
> a feature in the shared library, and instantly upgrade everything linked with
> it.  Let's say a bug was discovered in some standard libc function that would
> allow you to perform actions as the uid of the process using that libc
> function.  Oh, for the sake of argument, we'll say it was syslog() :-)  If you
> can get telnetd, or any of a very large class of executables that run as root
> to perform that call for you in the way you want, you're in a lot of trouble.
> If you can just patch the libc and maybe a handful of statically linked
> executables (how many things would run as root at the behest of a user are
> there that are statically linked on a normal system -- i.e., in /sbin?) you
> fix the hole.  Much easier than patching 50 different executables -- how long
> would it take for the vendor to recompile and release patches for that many
> things?!  I'd hate to think about fixing the syslog hole on such a system, it
> might as well be a system without shared libraries at all!  You essentially
> need to release a new rev of the OS as a carrot to get people to upgrade (not
> that that is any guarantee people do, but it is more likely than getting them
> to install dozens of patches)

I agree with this "most of the time". However there are instances when
small statically linked programs ARE desirable. For instance, if you
want to setup a chroot environment for some small thing.. Say, FTP for
instance. It is desirable to have a small statically linked ls instead
of having to copy over about 15 shared libraries into your chroot area.
In most cases outside of chroot environments, shared libraries are
preferable for upgrade and patch reasons.

This is just my opinion, so flame me if you want, but I'm not going
to change it. :)