Let me preface this by saying that most of this isn't very important. Most is arguing fine lines and grey areas and so it isn't anything for anyone to get upset about. I wanted to try to clarify a bit. Skip to the last two paragraphs if you are somehow reading this but don't care about minor details. (:

How do you suppose user blackhat will manage to predict

As I said, I don't have a plausible exploit handy. It was a 15-second demonstration of the race condition. Maybe he does something so low-tech as to peek over the cubicle wall.

But I still consider "check what files are there before you use 'perl -ne ... *' as root" to be pretty poor advice. Just don't use 'perl -ne ... *' as root until the problem is fixed (and check that root isn't using any Perl tools that use <> somewhere inside).

I can imagine the poor slob fixing his cron job to check for bad file names before running pgrep (as opposed to filtering out bad file names before feeding the filenames to pgrep or just fixing pgrep).

I never said "Perl is a poor tool". I suppose I could have been more precise and said something awkward like... well, something awkward. If you read "it will be sad day when" and think, "Well, nothing happy will happen the entire day of when that happens"? I consider the feature of executing filenames to be a pathetic feature. But big adjectives don't make for eloquent speech.

I guess you are right. I'm saying "CERT advisory" when I'm thinking of a broader concept that includes things like "SANS security alert".

There is no cause for a panic inducing advisory.

I really think "Don't use 'perl -ne ... *' as root" needs to be announced on several security alert streams. I don't think such needs to induce panic. I think it would be somewhat hard to word it so poorly that it would induce panic. *shrug*

The problem is with two-argument open() not just that perl uses it with <>, -p, and such

2-argument open just doesn't bother me near as much. I like to write open FH, "< $file\0" and have been doing that since Perl 4. That is every bit as safe as 3-argument open (if I am to believe the Perl 4 manuals) or the older sysopen. Sure, you can misuse 2-argument open and, as an interface design it affords such misuse and so isn't a great interface design. But I think <> goes a step beyond affording misuse, it makes it trivial to misuse and dang hard to use safely and the unsafe usage doesn't seem useful to me (as open says, the magic nature can be useful by making it easy for users to tell you to get your input from a command instead of a file).

But none of this is that important.

a slow graceful transition from the current default behavior to something sane. That seems to be the direction things are already going.

I hope so. I don't see that yet.