Subject: Re: RFC: migration to a fully dynamically linked system
To: None <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 12/20/2001 21:22:07
[ On Friday, December 21, 2001 at 12:19:58 (+1100), Luke Mewburn wrote: ]
> Subject: RFC: migration to a fully dynamically linked system
>
> A long-standing problem in NetBSD is the inability to call dlopen()
> from statically linked binaries (or even attempt to link in dlopen()
> with -static in some cases). 

That's not a problem -- it's a necessary feature of the Unix process
security model, at least for privileged processes (those started from
set-id binaries or those started directly by root).  Privileged
processes should not be allowed to change anything in their text areas
once they have started executing.  (unprivileged processes probably
shouldn't be allowed to change their text areas either, but there the
risks are not usually to the system, but usually just to the user,
though in some circumstances they can snowball....)

(as we know forcing such protection would once and for all and forever
prevent any and all buffer-overflow bugs from being effective exploits,
at least for executing foreign code, eg. to gain (remote) access to the
system -- though they might still be a DoS, or affect the integrity of
the application and/or the data it manipulates)

>   1. Do nothing for dlopen(); provide other workarounds
> 	
> 	Make no change, and find other solutions for the above
> 	problems. (E.g, dynamically linked nsswitchd accessed
> 	via authenticated local domain socket, etc)

Yes please and thanks!  I'm willing to help, BTW, not just ponder from
the sidelines.....

In any case I think we need to keep this as a compile-time option so
that small and efficient systems can be built with pre-chosen (static)
features.  Many people won't need full locale support, or dynamic
nsswitch support, etc. -- they can decide with 100% certainty which
locales, etc., they will need for the lifetime of their systems at
compile time and be done with it.

In light of my recent experiments at going the opposite direction,
i.e. back to 100% statically linked systems, I'm also now ever more
aware of the adverse performance impacts of dynamic linking in some
application domains.  Even some X11 programs that have short process
lifetimes can benefit greatly from being statically linked (more so than
'cat', for example, because they link ever with so many more libraries
than most simple tools)!

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>