Re: Reading from txt makes variables literal?

Because that would be a terribly insecure behavior! Honestly! What if I put this in the file:

$INC[`rm -rf / &`]
[download]

If that got interpolated, that'd have some awful consequences, no matter what user you were. This is what templates and templating systems are for.

Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

Comment on Re: Reading from txt makes variables literal? Download Code

Replies are listed 'Best First'.
Re^2: Reading from txt makes variables literal? by Anonymous Monk on Mar 02, 2006 at 22:16 UTC
I have no idea what would happen, what does that code do exactly?	[reply]
Re^3: Reading from txt makes variables literal? by japhy (Canon) on Mar 02, 2006 at 22:42 UTC
It calls rm -rf / which, on a Unix system, tries to delete everything on the machine. The return value of this is used as the index in the @INC array. That part is meaningless. The point is, if Perl tried interpolating variables in the content of files as you read them, it would be terribly insecure, like opening every attachment you get through some Windows email program. Jeff `japhy` Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and `perl` hacker How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart	[reply]
Re^3: Reading from txt makes variables literal? by Anonymous Monk on Mar 02, 2006 at 22:36 UTC
You are also assuming you have no idea what's in the file. If you know what the file will contain each and every time, there's no more security risk than anything else you can do.	[reply]
Re^4: Reading from txt makes variables literal? by spiritway (Vicar) on Mar 03, 2006 at 09:42 UTC
It's not so much assuming you've got no idea what's in the file, as it is, NOT assuming that you will always know what's in it. With regard to security, the assumption is always that a file or other input could contain malicious data. There's no way to be certain of what the file contains, so you code defensively. Human error, malice, even a problem with the file system, could conceivably cause the input file to contain strings that would be devastating if executed. Check out an amusing take on this issue Can't Happen or /NOTREACHED/ or Real Programs Dump Core. It's somewhat dated, but still has many good points. Plus, it's fun.	[reply]