Date: Tue, 18 Nov 2003 18:26:21 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Scott Long <scottl@freebsd.org> Cc: "M. Warner Losh" <imp@bsdimp.com> Subject: Re: Unfortunate dynamic linking for everything Message-ID: <200311190226.hAJ2QLtT096067@apollo.backplane.com> References: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> <20031118164905.R35009@pooker.samsco.home>
next in thread | previous in thread | raw e-mail | index | archive | help
:Our rationale for encouraging Gordon is as follows:
:
:1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want
: to upgrade from 4-STABLE. Historically in 4.x, the / partition has
: been very modest in size. One just simply cannot cram the bloat that
: has grown in 5.x into a 4.x partition scheme. Of course there is the
: venerable 'dump - clean install - restore' scheme, but we were looking
: for something a little more user-friendly.
This argument would apply to very old 4.x users but not to anyone who
installed it as of March 2001. I bumped the nominal size of the
root partition to 128MB in 1.98.2.7 of sysinstall/label.c.
Prior to that Jordan had bumped the root partition size to 100MB
in 1.98.2.3 in March 2001. It was 50MB before then, which is too small
even for 4.x.
:2. NSS support out-of-the-box: Again, this is a user-experience issue
: in that forcing NSS users to recompile world was seen as a potential
: roadblock to them.
Users have to recompile the world anyway, I don't think NSS is an issue.
Or to put it another way: Nobody in their right mind should be
contemplating upgrading a 4.x system to 5.x for production purposes.
There will simply be too much 4.x cruft left over. Upgrading
really requires a wipe and reinstall in this instance.
I seem to recall that the main reason 5.x went to a dynamic /bin was
to work around a terribly broken PAM design. The other issues were
just eye candy compared to the PAM problems. Personally speaking, I
think the solution is to fix PAM instead :-)
:3. Binary security updates: there is a lot of interest in providing a
: binary update mechanism for doing security updates. Having a dynamic
: root means that vulnerable libraries can be updated without having to
: update all of the static binaries that might use them.
Non-issue if you have an automatic security update mechanism or script
to do the work for the user, which we don't. Even so, /bin and /sbin are
sufficiently self-contained in the source hierarchy that recompiling and
reinstalling them is not a big deal.
I think the security argument is a red-herring because, frankly,
security problems are far more prevalient with ports and larger services
(Apache, sendmail, sshd, etc... mostly in /usr/bin and /usr/local),
and not as big an issue for /bin and /sbin.
:As for performance, we felt that the typical use of FreeBSD did not fall
:into the category of doing forkbomb performance tests. While there might
:certainly be users that do continuously create lots of short-lived
:processes, we felt that the above benefits outweighed this, but left the
:door open for tailoring to this need (recompiling world with
:NO_DYNAMICROOT).
fork() is a non-issue (forking overhead for a dynamic executable imposes
a slight time penalty but does not really impose any resource penalty).
However, I personally believe that anything run by a shell script is
an issue in regards to performance, and anything you exec multiple
separate copies of is an issue in regards to memory overhead. A system
running a large number of JAIL'd environments will wind up with a larger
number of swap-managed dirty pages.
But, all this aside, the reason I am decidedly against a dynamic /bin is
simply one of system recovery and safety. I've blown up /usr so many
times over the years that had /bin and /sbin been dynamic I would have
been in real trouble on many occassions.
If I recall correctly, some people have proposed and/or implemented some
sort of emergency fall back or safety bin in 5.x to make up for this
issue. I would humbly submit that this simply acknowledges that a dynamic
/bin and /sbin is a bad idea in the first place.
I do not intend to make /bin or /sbin dynamic in DragonFly by default.
I don't mind adding support for those people who want it, but I am not
going to make it the default.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311190226.hAJ2QLtT096067>