Thus spake Doug Rabson <[EMAIL PROTECTED]>:
> > > Move the resolver code out to, and link
> > > against so that legacy applications are happy, as
> > > long as they are compiled shared.  Non-network apps can ignore
> > > most of it.  Internal use of some of the biggest chunks is
> > > limited, so this should avoid dragging in a lot of it.
> >
> > We've been over this before.  To make this work right, we need to make
> > /bin and /sbin dynamically linked.  NetBSD's /rescue/* approach would
> > solve the "oops!" and other foot shooting problems.
> Yes please. Our root filesystem space requirements are too high, IMHO.

Why is it absolutely necessary to dynamically link everything just
to move the resolver out of libc?  I'm all for doing the latter,
but I think dynamically linking /bin and /sbin is a really bad
idea, for several reasons:

- If the single user mode runtime includes several shared
  libraries, you have several additional points of failure.

- The use of shared libraries incurs a performance hit for
  programs like sh and echo, which should be fast.
  o Exec time is greatly increased because you have to map in the
  o The -fPIC code in the shared libraries is slower, particularly
    on the register-starved i386.
  o The VM system has to do more work when you have a sparse virtual
    memory map, which is what you get when you stick shared libraries
    in the middle of your address space.

- Using shared libraries for trusted binaries like sh has negative
  consequences for security.  For example, a `feature' of OpenSSH
  allows users to circumvent restrictions imposed using /sbin/nologin,
  provided that /sbin/nologin is dynamically linked.

I don't think the disk space argument outweighs these problems.
There are a few binaries in /sbin that are bigger than they ought
to be, but it isn't as though /bin and /sbin occupy 500 MB.
Memory is even less of an issue; if a thousand copies of a shell
are running, their text gets shared regardless of how they are

I have run into problems with dynamic linking in the past.  In one
case, I couldn't log into a Linux machine because the
administrator (who used bash, of course) had tcsh linked against a
version of glibc that didn't exist on his system.  I would really
hate to see FreeBSD open itself up to the same kinds of
foot-shooting opportunities just because of the resolver, or for
the sake of a few dozen megs of disk space.  Of all things, don't
dynamically link my shell.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to