Bug#366124: apache2: should mark its listening socket close-on-exec

2007-07-22 Thread Stefan Fritsch
AFAIK mod_php has no facility to change the uid, so it is no security issue: As long as the uid stays the same, the spawned process can ptrace the apache process and do anything it wants anyway. FWIW, this is not true if the apache parent process runs as root. In this case the child

Bug#366124: apache2: should mark its listening socket close-on-exec

2007-07-22 Thread Stefan Fritsch
This is also discussed at http://bugs.php.net/bug.php?id=38915 There is the argument that mod_php should use apr_proc_create instead of using exec directly. So maybe we should reassing this to mod_php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble?

Bug#366124: apache2: should mark its listening socket close-on-exec

2006-11-12 Thread Stefan Fritsch
If Apache behaves like this, it's a security issue, especially if it occurs together with SuexecUserGroup. Non-privileged processes can intercept HTTP requests and impersonate the web server process. mod_cgi closes the socket (I checked 2.2) so it is only an issue with mod_php. AFAIK

Bug#366124: apache2: should mark its listening socket close-on-exec

2006-05-07 Thread Florian Weimer
* Marc Haber: (1) apache or something running inside the apache process (maybe a php script using mail()) sends e-mail using /usr/lib/sendmail. (2) exim, invoked as /usr/lib/sendmail, inherits the listening socket. If Apache behaves like this, it's a security issue, especially if it

Bug#366124: apache2: should mark its listening socket close-on-exec

2006-05-05 Thread Marc Haber
Package: apache2 Severity: wishlist Hi, the exim4 maintainers have received an increasing number of support cases where apache wouldn't start because there was an exim process listening on port 80. People keep suggesting a compromised exim and worse things. Only explanation I can come up with