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.
| [reply] |
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] |
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] |