Date: Wed, 30 Oct 2002 21:32:02 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Doug Rabson <dfr@nlsystems.com> Cc: Peter Wemm <peter@wemm.org>, Terry Lambert <tlambert2@mindspring.com>, Nate Lawson <nate@root.org>, current@FreeBSD.ORG Subject: Re: libc size Message-ID: <20021031053202.GA26280@HAL9000.homeunix.com> In-Reply-To: <20021030221417.J22480-100000@herring.nlsystems.com> References: <20021030214158.CB6EA2A88D@canning.wemm.org> <20021030221417.J22480-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Doug Rabson <dfr@nlsystems.com>:
> > > Move the resolver code out to ibresolv.so, and link libc.so
> > > against libresolv.so 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
libraries.
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
linked.
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021031053202.GA26280>