Have you ever run a Perl script as root? If so, did you read the entire source tree of modules that get included by that script to make sure not a single one of them did:

    my $data= do { local(*ARGV); @ARGV= $filename; <> };
[download]

But now I have to add Perl to my list of things to "never trust". Why? Because it isn't reasonable for me to constantly keep track of exactly which modules might have been updated and might have decided to start using <>. Yes, in the real world, you have to make assumptions based on imperfect information and so you have to sometimes put your trust into things that you haven't recently disassembled and digested completely.

The phrase

know what you are running when you are logged in as root

Now this <> brokenness means that I can't trust the most basic of Perl code. This is not how it should be. And it is easy to fix.

Juerd may be complaining about not having realized that <> will pass file names to the shell. I'm not. I don't care whether some people think I should have realized this or not. It is just plain stupid and broken as a design and should be changed, regardless of the existence of so-called documentation of this mis-feature.

I'm not even convinced of the validity of the "it is documented" argument. All of the documentation I recall on the subject was sufficiently vague. For example:

is equivalent to the following Perl-like pseudo code:     .... except that it isn't so cumbersome to say, and will actually work. It really does shift the @ARGV array and put the current filename into the $ARGV variable. [....]

You can modify @ARGV before the first <> as long as the array ends up containing the list of filenames you really want.

I think it's time to actualy fix this thing. I propose a new $^H (or %^H) hint that selects if ARGV magic open uses two-arg or three-arg open. What would matter is the value in effect at the moment of the open. I propose a pragmata to select it, and an additional "lock" feature, which would not allow changing the value after that point (in execution order, allowing it to be a feature of the module code, not the core).

IOW: use magic::ARGV qw(safe lock); allows you to trust all code from that point on. (use magic::ARGV qw(safe); wouldn't lock it in, so it could be explicitly overruled, use magic::ARGV qw(more-magic); would give back the old behaviour. All that's left is to get better names, perhaps change the default from more-magic to safe, and actualy code the thing.

Agree, disagree? Think I should be saying this on p5p already?

---

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).

As I said, I've already started down that road. I've made similar changes and know what code is needed. However, I won't waste my time finishing it until someone can convince p5p to accept it. The amount of work is not trivial due to some accumulation of hacks in how 2-arg vs. 3-arg open are handled. And I'm convinced p5p won't accept such a patch anyway.

I also refuse to try to convince p5p. I don't find them to be very susceptible to (my) logic. q-: (or, if you prefer, because it wouldn't work anyway -- someone else would have better luck convincing p5p)

See my p5p submission for more details.

                - tye

Without regard to the question of whether this particular feature is desirable, I think the maxim of 'know what you are running when you are logged in as root' remains important and relevant.

In that regard, the fact that a perl installation may regularly change as new modules are installed from CPAN should be seen as an issue to be addressed - CPAN modules do not get anything like the same level of checking as the core perl installation.

Perhaps, then, it would be advisable to install a version of perl specifically for the use of trusted scripts, with its own library path, and require a higher level of validation before any changes to that installation.

On my local system, I have a statically-linked perl in /sbin primarily so that scripts involved in startup/shutdown of the system can have a binary to use that doesn't need any other filesystems to have been mounted. I could certainly imagine orienting a security strategy for perl-as-root code around that installation.

Hugo

Please step into the real world, where it is your responsibility to know what you are running when you are logged in as root.

It is indeed. But as I said before, in the post that you quoted, people make mistakes. I believe your mistake was to not read my post or to interpret it the wrong way.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }