[ On Tuesday, January 25, 2005 at 16:14:48 (+0100), Joerg Sonnenberger wrote: ]
> Subject: Re: PAM and su -K
>
> The problem with a static universe is that no "modular" framework like
> citrus can work properly without knowing in advance which modules are
> needed and compiling the necessary hacks in.

And what, exactly, is the problem with that?

And if you want a truly dynamic execution environment then why the heck
aren't you using an interpreted language (or at least JIT
byte-code-compiled one)?!?!?!?

This perceived need for dynamic loading of machine code (as opposed to,
and separate from, shared libraries) is bogus in 99.99% of situations,
especially now that modern processors are fast enough to make even
languages like Smalltalk run at speeds well beyond those required for
implementing full real-time graphical user interace environments.


> This would be solved by
> allowing dlopen from static applications

Perhaps, but in addition to the problems Jason also mentioned, the mere
alloance of dlopen() from a static-linked program would completely
violate the security model those of us who want static linking depend
upon.

(I'm not sure it's tight enough as it is, but blatanly allowing it, and
worse, solving all the inherent problems of doing it right, would be a
hole the size of a barn door.)

> Also keep in mind that for the intended use, the overhead of PIC is
> very small or not existing, because the code itself is often called
> via function pointers anyway.

Maybe it is small on your choice of processors, but that is not true for
all, at least not according to the benchmarks I've run.

Keep in mind that all dynamic-loaded code _MUST_ be PIC on some CPUs.


Besides, for the likes of citrus the very idea of implementing it in
such a way that it requires dynamic loading of machine code is an
extremely poor design choice -- maybe it's easy to implement that way,
but it's wrong.


-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>