There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I think this should be changed. The default behavior should be just as you, tye, and others have pointed out. But, to put it in perspective, the problem isn't as terribly nasty as it has been made out to be in some posts here. Boil it down and it is simply a question of how much you can or should trust the source of your data. (And I think that was the real point Abigail was trying to make, even he went off on a bit of a tangent.) In other words, it's the same old issue that pops up time and again with CGI scripts. We constantly remind people that they can't trust the data submitted to their scripts so they really should use taint checking. We educate them. Continually. The only differences in the case of Perl, the diamond operator, and shell globs are:
A reasonable effort at following best practices will almost eliminate any potential danger from this infamous little "feature." There is no need for hyper-rigorous draconian super-sysadmining, which we all know is unrealistic anyway. Good habits are sufficient. Limit file and, especially, directory permissions. Use system accounts and groups to create sandboxes and segregate users.¹ Don't run processes, particularly automated ones, with greater privileges than necessary. Look at the files in a directory before you leap at them all willy-nilly with a splat on the command line.² These things are (or should be) second nature to experienced administrators. They are, afterall, the same measures that protect us against many far more subtle threats than a file named 'chown root:root somefile && chmod 4555 somefile|' which sits around waiting to get executed by an unsuspecting root privileged perl script foolishly making use of ARGV. Besides, whenever (or if) this is fixed, we'll still have to educate people on the dangers of using two argument open. Afterall, perl -e 'open F, $_ and print <F> for @ARGV' is no better than using -p. (Though, admittedly, perl isn't making the decision for you in that case.) The security implications are real, but the magnitude of the threat is actually small and completely avoidable. This behavior of perl's isn't exactly news but, as you point out, lots of experience Perl coders are unaware of it. That means two things: 1) there is room for more education and 2) it hasn't caused much of a problem over the years. I think that tye's call for a CERT advisory is a bit melodramatic. So, in summary, yeah; I think it should be changed. It's a minor security risk and, just as damnable and maybe moreso, it doesn't work as you'd expect. As tye pointed out, -p and ilk don't play nicely with filenames that start with whitespace. (They don't like files ending with whitespace either.) That's good enough reason to change it.
¹ In another post you said:
² Excuses like, "there are too many files in the directory to see all of them easily" don't hold up. If there are, then one shouldn't be using * anyway. There are always other choices like ls | less or a better constructed pattern to match exactly the desired files. -sauoq "My two cents aren't worth a dime."; In reply to Re: Dangerous diamonds!
by sauoq
|
|