perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Blakeley <m...@blakeley.com>
Subject Re: bogus taint error?
Date Mon, 03 Jul 2000 19:17:48 GMT
At 10:49 AM -0500 7/3/2000, Matt Carothers wrote:
>On Sun, 2 Jul 2000, Michael Blakeley wrote:
>
>>  This is just plain weird. My last resort was to turn taint off:
>>
>>  $ ls -l logs/httpd.pid
>>  -rw-rw-rw-   1 root     other          6 Jul  2 19:23 logs/httpd.pid
>>  $ grep -i taint conf/httpd.conf
>  > #PerlTaintCheck On
>>  $ ls -l conf/httpd.conf
>>  -rw-r--r--   1 root     other       7437 Jul  2 17:22 conf/httpd.conf
>>
>>  I'm not including any sort of startup.pl file. So taint is off, right?
>
>Is the script running setuid or setgid?  If the script's real and effective
>uids or gids don't match, perl enables taint mode automatically.  You might
>add some debugging code to verify that $< == $> and $( == $).

There's no sticky bit on the file, and the uid and gid of the file 
are the same as the apache user.

I think I may have an answer for taint's on-when-off behavior: I'd 
been syncing /usr/local/lib/perl5 all along, but it seems that some 
of the perl binaries may have drifted apart. Since syncing them up,
	#PerlTaintCheck On
seems to disable taint, as it should. I'm not sure what drifted out 
of sync - I haven't rebuilt perl, apache, or mod_perl in months.

But I still have to turn PerlTaintCheck off in production, even 
though the same script, on the same OS, with the same perl binaries 
and libraries, and the same mod_perl and apache binaries, works fine 
for dev. I'd love to understand why - a race condition triggered by 
high concurrency, maybe? So far I haven't been able to trigger it 
with ab -c 5 -n 1000 against the dev server.

-- Mike

Mime
View raw message