Re: suexec/946: The "User" directive fails for virtual hosts where the user differs from that for the main server. (fwd)

[Marc Slemko <ma...@znep.com>]

The following reply was made to PR suexec/946; it has been noted by GNATS.

From: Marc Slemko <ma...@znep.com>
To: apbugs@apache.org
Subject: Re: suexec/946: The "User" directive fails for virtual hosts where the user differs from that for the main server. (fwd)
Date: Thu, 31 Jul 1997 18:04:16 -0600 (MDT)

 
 
 
 ---------- Forwarded message ----------
 Date: Fri, 01 Aug 97 09:15:09 +1000
 From: Ronny Cook <ro...@tmx.com.au>
 To: marc@hyperreal.org
 Subject: Re: suexec/946: The "User" directive fails for virtual hosts where the user differs from that for the main server.
 
 > Date: Thu, 31 Jul 1997 07:23:42 -0700 (PDT)
 > From: Marc Slemko <ma...@hyperreal.org>
 > Subject: Re: suexec/946: The "User" directive fails for virtual hosts where the user differs from that for the main server.
 > 
 > Synopsis: The "User" directive fails for virtual hosts where the user differs from that for the main server.
 > 
 > State-Changed-From-To: open-analyzed
 > State-Changed-By: marc
 > State-Changed-When: Thu Jul 31 07:23:41 PDT 1997
 > State-Changed-Why:
 > I'm sorry, I don't understand what you are saying.
 > The server is not supposed to do a setuid() to use
 > suexec.  suexec is supposed to be setuid root, and it is
 > supposed to be run by the user the main server runs as.
 > 
 > Where is the problem?
 > 
 Well, I could say that "the User directive does not work for virtual hosts",
 which is what causes suexec to fail, but since "User" is only supposed to
 work when suexec is enabled, that's not stating the real problem. The
 suexec binary is fine. It might be that the bug belongs in the "core"
 category.
 
 The suexec documentation includes a paragraph which says:
 ] One way to use suEXEC is through the User and Group directives in
 ] VirtualHost definitions. By setting these directives to values different
 ] from the main server user ID, all requests for CGI resources will be
 ] executed as the User and Group defined for that <VirtualHost>. If only
 ] one or neither of these directives are specified for a <VirtualHost>
 ] then the main server userid is assumed.
 
 I took this to mean that I could use "User" and "Group" to enable suexec
 for particular hosts by compiling suexec to use one particular UID (in our
 case it's "cgiwrap") then using the User directive to force suexec to work
 only when a particular virtual host is being accessed. This doesn't work,
 basically because the *User* directive doesn't work (for virtual hosts). As
 nearly as I can tell, The User directive doesn't work because requests are
 farmed out to subservers which are already running under a non-root UID.
 
 It could be a documentation bug rather than a program bug, I suppose, but
 if so that begs the question of what is the server *supposed* to be doing
 with the User directive?
 
 Here's a snippet from our Apache configuration:
 
 ] User nobody
 ] Group nogroup
 ] 
 ] <VirtualHost 203.31.119.104>
 ] ServerAdmin     bahram@creative.com.au
 ] ServerName      ecash.tmx.com.au
 ] DocumentRoot    /usr/local/etc/httpd/htdocs/ecash
 ] ScriptAlias     /cgi-bin/       /usr/local/etc/httpd/htdocs/ecash/cgi-bin/
 ] User #599
 ] </VirtualHost>
 
 (User #599 is the cgiwrap user; I changed the UID to numeric form after my
 initial tests showed failure with that configuration).
 
 The intention here is to enable suexec only for the 203.31.119.104 virtual
 host. A kernel trace on the daemon while serving a request for the above
 virtual host shows no setuid calls; it could be that the User directive
 for a virtual host is simply being ignored.
 
 Incidentally, before you mention it, I do know that that particular
 configuration isn't particularly secure. It's strictly temporary.
 
 		...Ronny
 --
  Ronald Cook, Technical Manager - Message Handling Systems/The Message eXchange
  Email: ronny@tmx.com.au ----- Phone: +61-2-9550-4448 ---- Fax: +61-2-9519-2551
 
 All opinions are my own and not those of TMX unless explicitly stated otherwise.