Received: (qmail 72580 invoked by uid 501); 18 Jan 2001 05:24:25 -0000
Message-Id: <20010118052425.72579.qmail@apache.org>
Date: 18 Jan 2001 05:24:25 -0000
From: M Squared <msq-apache@msquared.com.au>
Reply-To: msq-apache@msquared.com.au
To: submit@bugz.apache.org
Subject: suexec not executed in VirtualHost with same User/Group as main server
X-Send-Pr-Version: 3.110

>Number:         7089
>Category:       suexec
>Synopsis:       suexec not executed in VirtualHost with same User/Group as main server
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          suspended
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          doc-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Jan 17 21:30:01 PST 2001
>Closed-Date:
>Last-Modified:  Wed Jan 17 23:36:56 PST 2001
>Originator:     msq-apache@msquared.com.au
>Release:        1.3.14
>Organization:
>Environment:
RedHat Linux 6.2 (pretty much a standard installation, plus updates from RedHat)
>Description:
suexec appears not to be executed in a VirtualHost where the User/Group in the VirtualHost is the same as that of the main webserver
>How-To-Repeat:
Create a VirtualHost with a different User and Group as the main webserver (say, joe).  Then, create a cgi in that host's documentroot and set its file permissions such that it is executed correctly.  A suitable script would be:

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print `whoami`;

This will tell you who it thinks it's running as (joe).

Once you have set the owner and mode of the cgi and the directory it is in so that suexec will run it, go ahead and run it.  Check that it is the correct user, and that there is a log entry in the suexec_log file.

Now, modify that VirtualHost so that the user and group is the same as the main webserver (say, httpd).

Now, access the cgi again, and note that it is running as the webserver user.  This is defined behaviour, except:

  * You didn't change the file ownership or permissions on the cgi.
  * There is no log entry for the cgi in the suexec_log

Note: I checked the documentation (http://httpd.apache.org/docs/suexec.html) and noted something.  I checked through the list of conditions that suexec checks, and point 10 (Is the target groupid ABOVE the minimum ID number?) should have triggered an error on my system.  Normal users are 500 and above, whereas httpd is 55.  Once again, note the lack of error message in suexec, and the fact that the script -did- successfully execute as httpd.
>Fix:
I suspect that the problem is somewhere in the Apache core, not suexec.  If it were in suexec, suexec should have complained about point 10 on that list.  I don't know how to fix it, but perhaps that might indicate where the problem lies...
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open-analyzed
State-Changed-By: slive
State-Changed-When: Wed Jan 17 23:27:55 PST 2001
State-Changed-Why:
This is the expected behaviour.  Suexec is only enabled
if the user or group specified is different than the
one for the main server.  In my opinion, this is the
most natural thing to do, and should not be changed.
However, you are correct that this should be documented
in the suexec docs.  I've marked this report as
"analyzed" so we can look at it when we improve the
suexec documentation.

Thanks for using Apache!
Class-Changed-From-To: sw-bug-doc-bug
Class-Changed-By: slive
Class-Changed-When: Wed Jan 17 23:27:55 PST 2001
State-Changed-From-To: analyzed-suspended
State-Changed-By: slive
State-Changed-When: Wed Jan 17 23:36:56 PST 2001
State-Changed-Why:

Hmmm... I guess "suspended" is a more appropriate state.
Sorry.
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]