[Talk] State of dynamic linking in various platforms...

[Luke Mewburn]

On Thu, Aug 22, 2002 at 02:58:09PM +1000, Peter Jeremy wrote:
  | >I'm working on a solution to making NetBSD have a dynamically linked
  | >"world", to solve a variety of problems (such as dlopen(3) not working
  | >for programs in /bin and /sbin because they're statically linked),
  | 
  | I think a more correct solution is add hooks so that it is possible
  | to call dlopen(3) from a static binary, rather than move to dynamic
  | linking.  I think this topic has been thrashed out recently on one
  | of the FreeBSD lists and people aren't keen to move to a fully
  | dynamically linked FreeBSD.

Suggested "solutions" for allowing static ELF binaries to use dlopen(3)
came up on the NetBSD mailing lists as well:
	- It breaks the ELF spec (so I'm told by the ELF gurus).
	- It's not trivial to implement.
	- There's many corner cases with libc global variable shadowing
	  (e.g, __sF[] in stdio).

These strike me as a hacks suggested by people who are dead set against
dynamic linking /bin and /sbin (usually for reasons such as "I got
screwed on Solaris once by this" (*)), so they come up with more &
more radical ideas (not working code, mind you) as solutions to each
of the objections, each idea more complicated than the last.  All to
avoid having a dynamic linked /bin.  (``KISS'', anyone?)

Ironically, they're generally happy with the current "half cocked"
solution that has /bin and /sbin statically linked and /usr/*
dynamically linked...  If they're that worried, why not fall back to
a fully statically linked system? (I bet 99% don't)

(*) For a long time I felt this way myself, because of lossage on a
Solaris box.  Implementing decent in-tree recovery tools removed my
objections.


  | Note that dynamic linking is not a cure-all for everything.  There are
  | security and performance reasons for retaining the ability to link
  | applications statically.

Sure, programs will still be able to be statically linked.
But they won't be able to take advantage of dynamically loaded
functionality such as:
	- third-party nsswitch modules
	- PAM
	- foreign locales
(and a bunch of other stuff that I'm sure could use dlopen(3)).

There are security advantages to dynamic linking as well, such as only
needing to upgrade /lib/libc.so.12 when there's a libc buffer overflow...
I can see arguments on both side of the "security" fence for this change.


Luke.