http://www.perlmonks.org?node_id=200234


in reply to Re: REALLY Private Methods in perl: Is Perl Flexible enough to be made Inflexible?
in thread REALLY Private Methods in perl: Is Perl Flexible enough to be made Inflexible?

And that only works until your attacker starts using magic (generally via B (something like (this is off the top of my head) B::svref_2object($obj)->PADLIST->ARRAY) to get access to your lexicals anyway. From what I can tell - if you can get a code ref to it then you can get it's lexicals. At that point there isn't any protection unless...

Ok, maybe... if you fork your process and orphan your objects via circular references and maybe if you are doing threading (which I gather is mostly a perl 5.8ism) you can still keep running code in those objects in a different process. Yeah, that's the ticket. (keep in mind this is just speculation)

Not that I think that would actually work but you have to go to some interesting lengths to keep your lexicals really, really private.

Update On further consideration just forking the process and allowing the private stuff to fall out of scope in the original process is enough to hide your stuff. Now you just have to do some sort of IPC to communicate back to the mother ship. ;-)

Replies are listed 'Best First'.
Re: Re: Re: REALLY Private Methods in perl: Is Perl Flexible enough to be made Inflexible?
by clintp (Curate) on Sep 24, 2002 at 00:06 UTC
    Ok, maybe... if you fork your process and orphan your objects via circular references and maybe if you are doing threading (which I gather is mostly a perl 5.8ism) you can still keep running code in those objects in a different process. Yeah, that's the ticket. (keep in mind this is just speculation)
    Then we'll just write perl modules to r00t your system. Once w3 0wn j00z, we'll go on to install loadable kernel modules to tinker in your process space directly. We'll use your lexicals from the inside out!

    :) for the humor-impaired