From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Thu, 22 Jun 2000 08:45:45 +0000 From: "Douglas A. Gwyn" Message-ID: <39519939.D7EB5345@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: , <10006200912.ZM59069@marvin> Subject: Re: [9fans] SO for plan9? Topicbox-Message-UUID: c6e67a98-eac8-11e9-9e20-41e7f4b1d025 Tom Duff wrote: > Shared libraries are the work of the devil, > the one true sign that the apocalypse is > at hand. Seriously, they're good for two > things, first for plug-in features, which > in plan 9 are often better handled by 9P > servers (obviously not always, for example > if there's an otherwise unachievable latency > or throughput requirement), and second for > giving third parties permission to break your > code after you've shipped it. I am stunned > and amazed that anybody that pays salary to > customer service reps would ever consider > using shared libraries. The two usual selling points are that installed applications benefit from bug fixes in the shared libraries (e.g. the standard C runtime library), and that it saves a *lot* of disk space, especially when big libraries are involved, as in X11. There are a lot of things wrong with shared libraries (or sometimes just with particular implementations); for one thing they make it fairly easy to break security; suppose a privileged process checks that you are allowed to perform some action then invokes a usually innocuous library function that you have prearranged in your substitute shared library (easy to do in Plan 9 where you own your name space) to perform some other action that you would not normally have been permitted to do. I've seen this in set-UID root UNIX programs (just found another yesterday) on systems such as Solaris where you can affect the runtime library directory search order (LD_*_PATH); it is easy to make such a program fire up a /bin/sh with inherited UID 0, which allows you to do anything at all!