> > if you mean the sunos-style shlibs which now dominate the industry,
> > i agree.  if you mean shared libraries in general, i DISagree.  look
> > at VMS or MPE for examples of how to do this in a secure and non-"plain
> > ugly" way.

> Can you please explain the "other ways" to get shlibs a bit more?

Sure.  The SunOS way, which netbsd uses, is a child's toy built on top of
mmap() and with hooks inside crt0.o (the outer block which calls main().)
In VMS and MPE, shared libraries are system level objects which are known
to the kernel's loader.  The files themselves are opened by the kernel at
boot time and are thus unwritable by normal user mode methods -- if one
wants to edit them one uses system calls designed for that purpose.  The
result is that you cannot remove symbols which are actively linked -- but
you can replace them.  There's enough indirection that you can change the
size of an object at replacement time -- there is no "load map".  And most
beautiful of all, there's an immutable audit log for all add/delete/replace
operations to active shared libraries.  Security wasn't an afterthought.

I'm not anti-UNIX.  The other systems are also toys in their own ways, and
do I run UNIX (BSD to be precise) and not VMS or MPE.  But the toyness runs
the opposite way when it comes to shared libraries.  UNIX's are just a toy,
and a broken toy at that.

Consider readdir() and its friends.  These used to be libc (user mode) calls
implemented in terms of read(), since directories were "just files."  Then
came NFS, and directories were abstract objects whose on-disk representation
was completely alien, and readdir() had to be made a syscall.  UNIX's model
called for simplicity and it turned out that there was a limit to how simple
you could make it and still meet the future on equal terms.  (I still recall
encountering pre-NFS compiled binaries whose readdir() worked fine as long
as the directory wasn't NFS-mounted -- try explaining THAT to a (l)user.)

So it is with mmap()'d shlibs that are mapped in at crt0.o (pre-main()) time.
The whole crock needs to be done away with and made into an LKM and the
shlibs ought to be open for exclusive access on kernel file descriptors at
the time init starts, and the shlib LKM should provide syscalls to ask the
kernel to serially, securely, and coherently modify the kernel-opened shlibs
that the kernel's loader knows how to search because the whole symbol table
is cached.

Right now whenever I edit a shlib I'm playing russian roulette.  Will the
system boot again after this change?  Only one way to be sure...  Do all the
apps that depend on this shlib still start?  Only one way to be sure...  Has
my shlib been modified by a cracker?  There's really no way to be sure...