>Number: 946 >Category: suexec >Synopsis: The "User" directive fails for virtual hosts where the user >differs from that for the main server. >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache (Apache HTTP Project) >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Thu Jul 31 01:30:01 1997 >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.2.1 >Environment: BSD/OS online.tmx.com.au 3.0 BSDI BSD/OS 3.0 shlicc2 (==gcc 2.7.2.1 for shared libraries) Patches K200-001, U200-001, U200-002. Apache was compiled separately. (The OS itself includes version 1.1.3). >Description: If an Apache configuration specifies a particular "User" for its base configuration and a different User for one of its virtual hosts, the setuid() for the virtual host fails, preventing execution of the suexec wrapper for that virtual host.
A system call trace seems to show that a subserver attempts to handle the request and fails because it is running under a different UID. >How-To-Repeat: http://ecash.tmx.com.au/shop/shop.htm fails because of this problem, but I'm sure that's less than helpful. Create an Apache configuration with a User directive of, for example, "nobody", and with a virtual host with a different user ("cgiwrap"). The suexec wrapper will be run as "nobody" rather than as "cgiwrap" because user "nobody" is not allowed to setuid(). >Fix: I suspect suexec really needs its own module to avoid this problem. Workaround: Run suexec scripts from a separate httpd running from inetd. Fix: Have any CGI invocations by virtual hosts be checked by the server for User directives before farming requests out to subservers. If there is a User directive present (different from the default), fork a new server >Audit-Trail: >Unformatted:
