Bert Freudenberg <bert at isg.cs.uni-magdeburg.de> is widely believed to have written:

> On Fri, 11 May 2001, phiho.hoang wrote:
> 
> >     I also suggested that we have a second look at the way the named
> > primitive mechanism is looking up the name for builtin primitives. Why can't
> > we consider the executable as another module housing the internal primitives
> > and treat internal/external primitives the same way (this is only do-able
> > for systems that support shared objects and equivalents).
> 
> Sounds good. That is, as long as there still is the possibility of
> ecternal modules overriding the internal versions.
Actually, it doesn't sound good at all. It is how we did things in
the first version of the plugins mechanism (v2.3-6 ish I think) and it
allowed all sorts of nasty tricks like executing 'exit()'. It is also
not at all portable, and so we moved to the newer mechanism.
> 
> It was also discussed a while ago that it would be cleaner and better
> security-wise to not use dynamic name lookup for the plugin functions but
> only for the pre-defined functions (setInterp, getName etc.), and have
> each module advertise a table of all its functions and addresses. The
> problem is that on various platforms it is not easy to limit the range of
> exported functions (like, all C runtime functions are accessible). It
> would also give some level of reflectivity wich is a Good Thing ;-)
This would be an improvement in my view and would be trivial to
implement. But....
> 
> So, if now is the time to overhaul the module stuff that could be included
> as well. I'd say it would even eliminate the whole namespace problem
> because no function names except for the "housekeeping" functions would
> have to be exported at all.
I don't think any overhaul is needed right now. It works very well, is
reasonably safe, secure and portable, and to mess around with it just to
make an obscure, unneccessary capability work seems foolish.

If people _really_ want the produced code for plugins to be the safe for
internal and external use then the only 'trick' needed is to make sure
the sqNamedPrims.h file is generated as part ofthe build. A tool could
be writen to scan all the plugins for internal use and fudge up a
suitable file. No need to change the lookup mechanism at all. A total
waste of effort in my opinion, but doable if you really insist.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
No program done by a hacker will work unless he is on the system.