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
