Sam Tregar wrote:
>
> On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > Well then. It is impossible to rearchitect it to make it shared
> > text? Perhaps the first instance of perl sets up some vast shared
> > memory segments and a way for the newcomers to link in to it and look
> > at the modules that have been loaded, somewhere on this system, and use
> > the common copy?
>
> That approach invites big security problems. Any system that involves one
> program trusting another program to load executable code into their memory
> space is vulnerable to attack. This kind of thing works for forking
> daemons running identical code since the forked process trusts the parent
> process. In the general case of a second perl program starting on a
> machine, why would this second program trust the first program to not
> load a poison module?
does sysV shm not support the equivalent security as the file system?
Did I not just describe how a .so or a DLL works currently?
Yes, the later Perls would have to trust the first one to load the modules
into the shared space correctly, and none of them would be allowed to
barf on the couch.
A paranoid mode would be required in which
you don't use the shared pre-loaded module pool.
In the ever-immenent vaporware implementation, this whole thing may
be represented as a big file into which we can seek() to locate stuff.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Yum, sidewalk eggs!
