Subject: Re: BSD auth for NetBSD
To: Greywolf <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 09/15/2003 17:24:58
[ On Monday, September 15, 2003 at 12:47:28 (-0700), Greywolf wrote: ]
> Subject: Re: BSD auth for NetBSD
> If something
> can be done by which statically linked binaries can do a modicum of dynamic
> loading, I, for one, would be both very appreciative and quite impressed.
I'd be very un-impressed with such a mechanism.
One of the major security-related features of static-linked programs is
that the processes they run as _cannot_ dynamically load new code.
Now if there were a more flexible "fake" libdl that could stub out all
the loading functions and just flip some pointers in a jump table to
select the entry-points for an already loaded and linked module, then we
could gain the benefit of static linking without having to change code....
That said though it must also be said that the vast majority of "plugin"
code that has to run in the same context and address space as the caller
is just an example of bad design. Use of multiple processes with a
fast, clean, local IPC mechanism beats the hell out of plugin code on
many fronts, losing only on raw simplicity and absolute maximum possible
Note that often in general purpose unix environments the cost of static
linking is easily offset by the savings gained from not having to run
ld.so on every invocation, and that goes double for anything which calls
the real dlopen() too. Jason's insult about static linking looks rather
hypocritical in face of all the work he did on a "real" vfork()
implementation, especially when you consider that the result is often
less than can be achieved simply by static-linking the programs which
get invoked many times during a larger job.
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>