Oh, I was thinking <>, the file-reading operator, not the specific code <> (AKA <ARGV>). Tye, I can see their point, that it changes the meaning of existing code... but making it taintable, putting a warning in the docs, and making an optional and fatalable default-on warning are are certianly called for -- just not silently changing the behaivor. OK, possibly changing existing behavor to make the <ARGV> magic use three-arg open, but only with a BIG FAT WARNING and a pragmata to change the behivor back.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply] [d/l] [select] |
To "fix" this would fix more existing code than it would break existing code. In fact, this sounds like something that should be in a CERT advisory not something to be kept for backward compatability.
The amount of code that intends to take advantage of this behavior is tiny. The amount of code at risk because of this behavior is huge.
My choice would be to require
use open IN => ":magic";
to get the current (hopefully soon to be "old") behavior rather than sane behavior.
And tainting isn't much of a solution. It is very easy to see situations where privileged users run a not-tainted script that looks up filenames from directories where less-privileged users can create files. For any reasonable program, this is a safe thing to do and so is not something people worry about or use "tainting" to protect against.
- tye | [reply] [d/l] |