Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Taint mode in Windows 1

Status
Not open for further replies.

icrf

Programmer
Dec 4, 2001
1,300
0
0
US
First system details:
Windows 2000
mod_perl2 (Perl 5.8.0 and Apache2)

CGI scripts are set to execute via the "ScriptInterpreterSource registry" setting pointing them to the perl interpreter. However, I'm interested in having some scripts, not all, use taint mode. I don't want to have to deal with it in simple test scripts, but I would like it available in production-level scripts.

If I include a shebang at the top, such as:
Code:
#!/usr/bin/perl -T
it fails to execute, dropping this message:
Code:
Too late for "-T" option at test.cgi line 1.
First off, it shouldn't even be looking at that. It's far from a valid path on this system, and since it used the registry, that line should be nothing more than another comment.

I assume from that error that taint must be turned on at execution time and can't be done from within code (though I hope not). But since I'm using the registry to launch the scripts, I don't want to set that option there for ALL scripts to run with, so I'm back to the beginning again. It feels like it's something simple I'm overlooking.

Can taint be turned on from the code body during execution, or is there some other way to set this for a script?

----------------------------------------------------------------------------------
...but I'm just a C man trying to see the light
 
icrf,
This one has come up a few times, are you running the script from the command line, if so use perl -T myscript.pl

HTH
--Paul

It's important in life to always strike a happy medium, so if you see someone with a crystal ball, and a smile on their face ...
 
No, they're CGI scripts started by Apache. And it's not using the shebang line, so I can't put it there. It uses the registry to find the perl interpreter. I could put the -T switch in the registry, but then EVERY script would have taint mode on, which would be more of a hassle than I want.

This is just a test/dummy computer. All these scripts eventually get to Hong Kong and run in RedHat, so I'd like to leave the shebang for that server in there and have my local machine ignore the line, but I can't selectively turn on taint mode.

----------------------------------------------------------------------------------
...but I'm just a C man trying to see the light
 
Perl will interpret your shebang line whether it is a valid path or not. According to the perlrun man page:

[tt]Parsing of the #! switches starts wherever ``perl'' is mentioned in the line. The sequences ``-*'' and ``- '' are specifically ignored so that you could, if you were so inclined, say

#!/bin/sh -- # -*- perl -*- -p
eval 'exec perl -wS $0 ${1+"$@"}'
if $running_under_some_shell;
to let Perl see the -p switch.[/tt]

In the 'doze environment, you could make your cgi program a batch file which starts perl with the -T flag on the command line. One batch file would suffice for all your perl programs as it could forward its own parameters after the -T.

You would then need to reconfigure your webserver to run the batch file as the interpreter, rather than perl.exe, but you wouldn't have to change your scripts or the pages that call them.

...which makes me think: could you specify the -T flag as part of the interpreter invocation in the web server configuration?

Yours,


fish
 
Well, if I could help it, I'd like to be able to selectively turn taint on or off on a per-script basis. I get the impression that what you're suggesting would work for all scripts. Since it's obtaining the interpreter path from the association with a .cgi file, I could easily add the -T switch there and make it work for all. More quotes from perlrun:

The #! line is always examined for switches as the line is being parsed. Thus, if you're on a machine that allows only one argument with the #! line, or worse, doesn't even recognize the #! line, you still can get consistent switch behavior regardless of how Perl was invoked, even if -x was used to find the beginning of the program.

Sounds hopeful. But:

-T
forces "taint" checks to be turned on so you can test them. Ordinarily these checks are done only when running setuid or setgid. It's a good idea to turn them on explicitly for programs that run on behalf of someone else whom you might not necessarily trust, such as CGI programs or any internet servers you might write in Perl. See perlsec for details. For security reasons, this option must be seen by Perl quite early; usually this means it must appear early on the command line or in the #! line for systems which support that construct.


Suggests that I'm not turning taint on early enough, which agrees with the error message. It sounds like I may not be able to do what I'm attempting at all. At least it answers the question of why it was even seeing the shebang and how it was reacting to what was there. I'm all ears if someone has an idea, otherwise I'll learn to live with taint everywhere like I learned to live with strict, which has turned out for the better.

----------------------------------------------------------------------------------
...but I'm just a C man trying to see the light
 
This Win2k computer it's running on is just my local test box. Its final destination is RedHat, which would use a very different shebang. I was just going to have the remote path in every script and I wouldn't have to change anything on the migration. No, it's not too big of a deal, my question was just wondering if it were possible. Now that it looks like it's not, I'll simply deal with it.

Thanks, everyone, for your time and thoughts. It is much appreciated.

----------------------------------------------------------------------------------
...but I'm just a C man trying to see the light
 
icrf,

What about a different extension for "taint" perl files?
And perhaps a simple housekeeping routine to replace your shebang line, and rename files prior to their shift to Hong Kong

--Paul

It's important in life to always strike a happy medium, so if you see someone with a crystal ball, and a smile on their face ...
 
icrf,

There is no reason for a *nix box and a windows box to use a different shebang syntax.

If your RedHat machine uses #!/usr/bin/perl then reinstall perl on your windows machines if it is not in the same location. When you install it on windows and are asked for the install path, choose the same drive as the server files and install to /usr/

So if Apache is on drive C: you would install to C:\usr\ and then use the shebang lie #!/usr/bin/perl in your scripts.

Many people do not realise that you can do this but it is perfectly valid on a windows machine with apache.

Hope this helps

Wullie


The pessimist complains about the wind. The optimist expects it to change.
The leader adjusts the sails. - John Maxwell
 
I remember something recently - I think it was from the release notes of Perl 5.8.0 - which suggested that Taint mode will not be with us for much longer. They (perl5 authors) have been trying to get it right for ages an are abut to give up on it altogether.

I don't rely on Taint anymore basically.

Mike

Want to get great answers to your Tek-Tips questions? Have a look at faq219-2884

It's like this; even samurai have teddy bears, and even teddy bears get drunk.
 
Taint and mod_perl, quite a common problem. First off the shebang line. Wullie, it makes no difference where you install Perl, the -T will still not work under mod_perl. Your suggestion has been mentioned before though and I will be updating the FAQs once I get the time.

However, there is a solution to your problem. Make your CGI parameters taint safe anyway, without having taint on. There are several modules to help the following being 6 I have found on CPAN:

* Params::Check - * Params::Validate - * Data::FormValidator - * CGI::Untaint - * CGI::Validate - * CGI::ArgChecker -
Even though you can't turn on taint checking, you can still ensure you have untainted your parameters.

Barbie
Leader of Birmingham Perl Mongers
 
The only things I noticed in perldelta about tainting are patches on inconsistent behavior and extending it to system calls, warnings only for now, but soon to be fatal. It wouldn't surprise me to see it go, and I don't read as much Perl development as I'd like, so I won't refute.

I had seen taint around and it seemed like a good idea, but I'd never used it much at all before and was going to try and force better habits on myself. I picked up this snippet some time ago from this board (I'm thinking from Barbie, but I don't remember), which gets the point across how it could easily be done:
Code:
my %cgiparams = ();
my $cgi = new CGI();
foreach my $name ($cgi->param) {
    my $value = $cgi->param($name);
    next unless($value);
        
    $cgiparams{$name} = $value if($rules{$name} && $value =~ /^$rules{$name}$/);
}
It doesn't only do parameter checking. In defining a pattern for all acceptable values, it's also a script input template(wherever %rules is defined), useful in documentation. So I'll leave taint off and use something like that to do checking anyway. Seems to be problems with search.cpan.org right now, but I'll be sure to check out those modules later.

----------------------------------------------------------------------------------
...but I'm just a C man trying to see the light
 
Yep thats my code :)

One of the reasons I was looking into the 6 modules mentioned, is that while the code mentioned is okay, I wanted a better taint checker for my CGI. There is a lot of business logic that can be implement with some of them, eg username or password checking, which goes beyond just the taint checks, while others implement the use of Regexp::Common [1], which already features regular expressions for many of the form fields you might use.

[1]
Barbie
Leader of Birmingham Perl Mongers
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top