You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by David Welton <da...@gmail.com> on 2005/06/21 18:24:49 UTC

httpd 1.3 mod_cgi argv[0]

[ Please CC replies to me - thankyou! ]

Hi, I've managed to tickle an obscure bug in Tcl's environment
introspection by launching a 'starpack' (self contained Tcl
executable+script) as a CGI. (*)

here is the relevant bit of strace:

4763  execve("/usr/lib/cgi-bin/protect.cgi", ["protect.cgi"], [/* 25
vars */]) = 0

My question is this: why doesn't argv[0] get the full path of the
file?  It's not like the CGI can't figure it out from the cwd and the
argv0 it does get.  The Tcl folks are wondering why Apache does things
this way, and I think it's a reasonable question.

Thankyou,
-- 
David N. Welton
 - http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
 - http://www.dedasys.com/

(*) http://sourceforge.net/tracker/index.php?func=detail&aid=1224888&group_id=10894&atid=110894

Re: httpd 1.3 mod_cgi argv[0]

Posted by David Welton <da...@gmail.com>.
On 6/26/05, Joe Orton <jo...@redhat.com> wrote:
> On Thu, Jun 23, 2005 at 11:23:55AM +0200, David Welton wrote:

> > 4763  execve("/usr/lib/cgi-bin/protect.cgi", ["protect.cgi"], [/* 25
> > vars */]) = 0
> >
> > My question is this: why doesn't argv[0] get the full path of the
> > file?  It's not like the CGI can't figure it out from the cwd and the
> > argv0 it does get.  The Tcl folks are wondering why Apache does things
> > this way, and I think it's a reasonable question.  The problem for Tcl

> I think the current behaviour is actually just a fall-out from the way
> that the code checks whether the script is an nph- script or not
> (searching for the basename and then comparing against "nph-").  In 2.0
> with mod_cgi, the argv[0] really is set to r->filename as you expect,
> though the same is not true of mod_cgid.

I was sort of hoping one of the 'old timers' might have a recollection
of a reason behind this, but I guess it may just be an artifact of how
things were originally put together.  The 'problem' is pretty obscure
and apparently not many people have noticed it.

> So upgrading to 2.0 is one solution, at least. I'm not sure it would be
> a great idea to change something this subtle in 1.3 now.

Could well be.  In any case, Tcl also needs to be 'more liberal with
what it accepts' even if that data is not ideal, so a fix should
happen there as well.

Thankyou,
-- 
David N. Welton
 - http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
 - http://www.dedasys.com/

Re: httpd 1.3 mod_cgi argv[0]

Posted by Joe Orton <jo...@redhat.com>.
On Thu, Jun 23, 2005 at 11:23:55AM +0200, David Welton wrote:
> [ Ok, trying this again as a subscriber... I guess the list mods missed it:-/ ]
> 
> Hi, I've managed to tickle an obscure bug in Tcl's environment
> introspection by launching a 'starpack' (self contained Tcl
> executable+script) as a CGI. (*)
> 
> here is the relevant bit of strace:
> 
> 4763  execve("/usr/lib/cgi-bin/protect.cgi", ["protect.cgi"], [/* 25
> vars */]) = 0
> 
> My question is this: why doesn't argv[0] get the full path of the
> file?  It's not like the CGI can't figure it out from the cwd and the
> argv0 it does get.  The Tcl folks are wondering why Apache does things
> this way, and I think it's a reasonable question.  The problem for Tcl

I think the current behaviour is actually just a fall-out from the way 
that the code checks whether the script is an nph- script or not 
(searching for the basename and then comparing against "nph-").  In 2.0 
with mod_cgi, the argv[0] really is set to r->filename as you expect, 
though the same is not true of mod_cgid.

So upgrading to 2.0 is one solution, at least. I'm not sure it would be 
a great idea to change something this subtle in 1.3 now.

Regards,

joe

httpd 1.3 mod_cgi argv[0]

Posted by David Welton <da...@gmail.com>.
[ Ok, trying this again as a subscriber... I guess the list mods missed it:-/ ]

Hi, I've managed to tickle an obscure bug in Tcl's environment
introspection by launching a 'starpack' (self contained Tcl
executable+script) as a CGI. (*)

here is the relevant bit of strace:

4763  execve("/usr/lib/cgi-bin/protect.cgi", ["protect.cgi"], [/* 25
vars */]) = 0

My question is this: why doesn't argv[0] get the full path of the
file?  It's not like the CGI can't figure it out from the cwd and the
argv0 it does get.  The Tcl folks are wondering why Apache does things
this way, and I think it's a reasonable question.  The problem for Tcl
is that it wants to know the full path of the executable, which would,
in this case, be /usr/lib/cgi-bin/protect.cgi, but it's not obvious
how to work that out from just 'protect.cgi' in a generic way.  It's
easy enough to do if you know it's a CGI, but Tcl can't contain code
just for CGI's without full-path argv0's.

Thankyou,
--
David N. Welton
 - http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
 - http://www.dedasys.com/

(*) http://sourceforge.net/tracker/index.php?func=detail&aid=1224888&group_id=10894&atid=110894


-- 
David N. Welton
 - http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
 - http://www.dedasys.com/