Note: please don't spam any of the e-mail addresses which you see here. Follow this link if you want some addresses to misuse.
From: David Chappell <David.Chappell@trincoll.edu>
Date: Fri, 08 Aug 2003 11:17:32 -0400
Subject: Re: PPR: ppop vs. PPOP.pm saga continues@trincoll.edu
Ahhh! I logged in from home to get this out first thing this morning.
I just noticed that it bounced because it didn't like the precise way my
e-mail address appears on e-mail from my home machine!
Kenneth Tindle wrote:
>> David,
>>
>> I have good news and bad news.
>>
>> You were right: open2() did care about the environment being tainted.
>> But it still does not work.
>>
>> a)I applied your fix to PPOP.pm
>> b)Ran ./show_queues.cgi
>> c)Got a taint complaint about {BASH_ENV}
>> d)Ran strace -o show_queues-1.log -f ./show_queues.cgi
>> to capture this state for examination
OK, I see that.
>> e)Added three new lines to PPOP.pm to mirror your fix,
>> but this time unset BASH_ENV as well as PATH
>> f)Ran ./show_queues.cgi, and did not see an obvious complaint
>> g)Tried it in a browser, it still didn't work "ppop not ready"
>> h)Ran strace -o show_queues-2.log -f ./show_queues.cgi
This is very intersting. It looks to me like it runs right from the
command line. This may means that when run out of Xinetd, the program
is poisoned in some way. The poison either prevents ppop from being
executed or causes it to die stillborn, before it can print any
messages. Possiblities include:
* Shared library differences
* Resource limits
* Environment variables
* Obscure bugs in PPR, the C libraries, or the kernel triggered by
seemingly irrelevant factors such as whether stdout is a terminal.
Try this as root:
# ~ppr/lib/ppr-httpd --standalone-port=15011
This starts a standalone copy of the PPR HTTP servers on a different
port. Now point your browser at it on port 15011 and see what happens.
If that works, we have to figure out what is different when it is run
out of Inetd. Do this:
* Load http://localhost:15010/cgi-bin/test_cgi.cgi in a browser, press
one of the submit buttons, and print out the list of environment
variables which you get.
* do this as root:
# killall xinetd
# /usr/sbin/xinetd
This will make programs launched by Xinetd descendents of your shell
instead of more direct children of Init.
* See if the web interface on port 15010 works now.
* If it does, load http://localhost:15010/cgi-bin/test_cgi.cgi again,
press one of the submit buttons, and note how the enviroment is
different. See anything?
>> i)Looking at the log, Perl seems mad about a missing multi-
>> thread environment, so
>> j)Ran rpm -qa | grep perl > perl-list
I am not sure what you mean. Can you tell me the line?
>> For the sake of further laughter, I ran my previous little
>> test script as both ppr and pprwww, and it worked OK.
Does it run as a CGI script? Put this at the begining and try:
print "Content-Type: text/plain\n\n";
>> How well would the new de-tainted PPOP.pm work if dropped
>> into the slightly older ppr 1.50a2?
I don't know. It might not work at all.
>> I can't believe this isn't working yet, after all this crap!
>> I wouldn't believe it if I didn't see it myself.
I believe you. :-)
================================================================
David Chappell David.Chappell@Mail.Trincoll.Edu
Computing Center Postmaster@Mail.Trincoll.Edu
Trinity College (860) 297-2114
Hartford, Connecticut 06106
U.S.A.