mod_cgi/1470: argv[0] passed to CGI scripts with and without suexec

[Greg Colyer <gr...@elysium.demon.co.uk>]

>Number:         1470
>Category:       mod_cgi
>Synopsis:       argv[0] passed to CGI scripts with and without suexec
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Mon Nov 24 03:50:01 PST 1997
>Last-Modified:
>Originator:     greg@elysium.demon.co.uk
>Organization:
apache
>Release:        1.2.4
>Environment:
Linux 2.0.30
>Description:
Apache passes the absolute pathname as argv[0] to CGI scripts which are not run
through suexec; suexec, however, gets passed (and passes on) only the relative
pathname. Thus: /home/greg/public_html/cgi-bin/test.cgi in the first case and
test.cgi in the second.
>How-To-Repeat:
Run a test CGI script via the main server address and via a virtual host that
has a User directive (with suexec configured).
>Fix:
It would be nice if "things looked the same as possible" for scripts,
regardless of whether or not suexec had been invoked. There may be security
reasons for the relative case: scripts cannot bypass this by calling
getcwd, if they do not have enough permissions on all parent directories.
(However, at present Apache makes the information available to them anyway in
SCRIPT_FILENAME.) Possibly the relative case is more "Unixy"? The CGI spec
doesn't seem to say anything about it. The relative case breaks scripts
which rely on the absolute case. (They shouldn't do, I suppose, but it has
been the default Apache behaviour.)

For security reasons (see another PR) I believe that suexec should only be
passed a relative pathname, as it now is. However, it could generate an
absolute one for the script, using getcwd itself, so this does not bear
directly on the decision
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]