Mailing List Archive

#exec cgi PATH_INFO bugs (repost)
I'm reposting this patch, because I missed bug.

In apache 0.8.7 and 0.8.8 (and earlier versions), for a parsed html file
containing a <!--#exec cmd -->

PATH_INFO was set, even if NULL.
PATH_INFO was erroneously shell-escaped. (Fixed with new patch)
If PATH_INFO was unset, PATH_TRANSLATED was set to the directory containing
the shtml file.
PATH_TRANSLATED might not contain all the translated path.
e.g. if the URL was /test.shtml/index.html/wibble
then PATH_INFO would be /index.html/wibble
but PATH_TRANSLATED would only be /docroot/index.html
If the URL contains encoded '%' characters then PATH_TRANSLATED might
be incorrect.

Fix: copy the code for setting PATH_INFO and PATH_TRANSLATED from
mod_cgi.c to mod_include.c, replacing the code in include_cmd_child.
This guarantees that the two methods of invoking CGI scripts are
(bug for bug) compatible.

When will 0.8.9 be released?

David.

---------------- begin file inc.patch2 ---------------------------
*** mod_include.c.orig Tue Aug 1 01:47:02 1995
--- mod_include.c Tue Aug 8 10:52:52 1995
***************
*** 408,423 ****
#ifdef DEBUG_INCLUDE_CMD
FILE *dbg = fopen ("/dev/tty", "w");
#endif
-
- request_rec *pa_req = sub_req_lookup_uri (r->path_info, r);
char err_string [MAX_STRING_LEN];

#ifdef DEBUG_INCLUDE_CMD
fprintf (dbg, "Attempting to include command '%s'\n", s);
#endif
!
! table_set (env, "PATH_INFO", escape_shell_cmd (r->pool, r->path_info));
! if (pa_req->filename) table_set (env, "PATH_TRANSLATED", pa_req->filename);

if (r->args) {
table_set (env, "QUERY_STRING", r->args);
--- 408,431 ----
#ifdef DEBUG_INCLUDE_CMD
FILE *dbg = fopen ("/dev/tty", "w");
#endif
char err_string [MAX_STRING_LEN];

#ifdef DEBUG_INCLUDE_CMD
fprintf (dbg, "Attempting to include command '%s'\n", s);
#endif
!
! if (r->path_info && r->path_info[0] != '\0')
! {
! request_rec *pa_req;
!
! table_set (env, "PATH_INFO", r->path_info);
!
! pa_req = sub_req_lookup_uri(escape_uri(r->pool, r->path_info), r);
! if (pa_req->filename)
! table_set(env, "PATH_TRANSLATED",
! pstrcat(r->pool, pa_req->filename, pa_req->path_info,
! NULL));
! }

if (r->args) {
table_set (env, "QUERY_STRING", r->args);
---------------- end file inc.patch2 ---------------------------
Re: #exec cgi PATH_INFO bugs (repost) [ In reply to ]
Date: Tue, 8 Aug 95 11:03 BST
From: drtr@ast.cam.ac.uk (David Robinson)
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

I'm reposting this patch, because I missed bug.

In apache 0.8.7 and 0.8.8 (and earlier versions), for a parsed html file
containing a <!--#exec cmd -->

PATH_INFO was set, even if NULL.
PATH_INFO was erroneously shell-escaped. (Fixed with new patch)

Sigh... once again, this is not "erroneous", and "fixing" it would be
both improper and dangerous. Anyone with a shell script invoked
through <!--#exec cmd-->, who is counting on the escaping to keep it
safe, would not view naked shell metasyntax as a favor.

If you want to "fix" this, the way to do it is to add a new variable,
PATH_INFO_UNESCAPED (which would parallel the way that QUERY_STRING
is dealt with by <!--#exec cmd=""-->). With regard to this patch, I
have to give it a -1.

Fix: copy the code for setting PATH_INFO and PATH_TRANSLATED from
mod_cgi.c to mod_include.c, replacing the code in include_cmd_child.
This guarantees that the two methods of invoking CGI scripts are
(bug for bug) compatible.

<!--#exec cmd=""--> commands are *not* CGI scripts, so there is no
compatibility issue; for instance QUERY_STRING is also handled
differently by the two mechanisms, as mentioned above.

rst
Re: #exec cgi PATH_INFO bugs (repost) [ In reply to ]
Rst wrote:
> Date: Tue, 8 Aug 95 11:03 BST
> From: drtr@ast.cam.ac.uk (David Robinson)
> Precedence: bulk
> Reply-To: new-httpd@hyperreal.com
>
>> I'm reposting this patch, because I missed bug.
>
> In apache 0.8.7 and 0.8.8 (and earlier versions), for a parsed html file
> containing a <!--#exec cmd -->
>
> PATH_INFO was set, even if NULL.
> PATH_INFO was erroneously shell-escaped. (Fixed with new patch)
>
>Sigh... once again, this is not "erroneous", and "fixing" it would be
>both improper and dangerous. Anyone with a shell script invoked
>through <!--#exec cmd-->, who is counting on the escaping to keep it
>safe, would not view naked shell metasyntax as a favor.

So use the patch I sent yesterday which left in the shell escaping.

David.