DO NOT REPLY [Bug 10243] New: - CGI scripts not getting POST data

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10243>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10243

CGI scripts not getting POST data

           Summary: CGI scripts not getting POST data
           Product: Apache httpd-1.3
           Version: 1.3.25
          Platform: Sun
        OS/Version: Solaris
            Status: NEW
          Severity: Major
          Priority: Other
         Component: core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: Rob.McMahon@warwick.ac.uk


Having installed Apache 1.3.26 to fix the chunking vulnerability I was reminded
of this problem which also occurred in 1.3.19, and which I think I forgot to
report at the time.  The symptoms are that CGI scripts get no POST data. 
Specifically, perl scripts using 

use CGI;
$q = new CGI;
@names = $q->param();

get no POST parameters.

Tracing this back showed that stdin to the script was in fact closed.

Much trussing later, it turns out that stdin is being closed in the call of
ap_cleanup_for_exec from cgi_child, because the accepted() socket in child_main
(csd) was in fact fd 0.  Looking at the daemons, fd 0 is in fact closed
normally, though fd 1 is /dev/null.

Looks like this may be happening in PHP (4.0.5) and I'll try to track down
exactly what's going on. The close(0) occurs after opening all the log files,
and before reading php.ini.

Defensively it seems to me that when spawn_child_core does its file descriptor
manipulation, it should be careful to remove any cleanups for the new setup.  In
any case this patch to src/main/alloc.c fixes (works around ?) the problem and
feels right:

*** alloc.c	2002/06/26 10:28:22	1.1
--- alloc.c	2002/06/26 10:29:16
***************
*** 2008,2013 ****
--- 2008,2015 ----
  API_EXPORT(void) ap_kill_cleanups_for_fd(pool *p, int fd)
  {
      ap_kill_cleanup(p, (void *) (long) fd, fd_cleanup);
+     for (p = p->sub_pools; p; p = p->sub_next)
+ 	ap_kill_cleanups_for_fd(p, fd);
  }
  
  API_EXPORT(int) ap_popenf(pool *a, const char *name, int flg, int mode)
***************
*** 2522,2539 ****
--- 2524,2544 ----
  
  	if (pipe_out) {
  	    close(out_fds[0]);
+ 	    ap_kill_cleanups_for_fd(permanent_pool, STDOUT_FILENO);
  	    dup2(out_fds[1], STDOUT_FILENO);
  	    close(out_fds[1]);
  	}
  
  	if (pipe_in) {
  	    close(in_fds[1]);
+ 	    ap_kill_cleanups_for_fd(permanent_pool, STDIN_FILENO);
  	    dup2(in_fds[0], STDIN_FILENO);
  	    close(in_fds[0]);
  	}
  
  	if (pipe_err) {
  	    close(err_fds[0]);
+ 	    ap_kill_cleanups_for_fd(permanent_pool, STDERR_FILENO);
  	    dup2(err_fds[1], STDERR_FILENO);
  	    close(err_fds[1]);
  	}

Sorry, don't know how to reproduce for other people, and I don't know why it's
only happening to me.  For me it's every time, and you can see descriptor 0
getting closed during initialisation.

Apache/1.3.26 (Unix) PHP/4.0.5 DAV/0.9.15 mod_ssl/2.8.9 OpenSSL/0.9.6d mod_perl/1.27

Happens for all versions from 1.3.19 through to 1.3.26.

> uname -a
SunOS crocus 5.8 Generic_108528-10 sun4u sparc
> 

Please let me know anything else I can do to help you with this problem.

Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org