suexec-custom is not working correctly: only reading the www-data user config file.

Bug #890219 reported by Thomas Woidt
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apache2 (Ubuntu)
Won't Fix
Medium
farhan saleh robleh

Bug Description

For some security and performance testing on PHP we installed a new webserver with ubuntu 10.04 LTS.
One of the goals is to run a custom php5 ini based on the user, I installed following stack:
apache2-suexec-custom: 2.2.14-5ubuntu8.7
apache2-mpm-worker: 2.2.14-5ubuntu8.7
php5-cgi: 5.3.2-1ubuntu4.10

The first testing user is called rootweb, his apache config is the following:
root@hosting1:/etc/apache2/suexec# cat /etc/apache2/sites-enabled/rootweb
<VirtualHost *:80>
 ServerAdmin webmaster@rootweb
 ServerName rootweb.test (=> modification of /etc/hosts file on the client for testing)

        SuexecUserGroup rootweb rootweb

 DocumentRoot /home/rootweb/public

 ScriptAlias /cgi-bin/ /home/rootweb/cgi-bin/
 <Directory "/home/rootweb/cgi-bin">
  AllowOverride None
  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
  Order allow,deny
  Allow from all
 </Directory>

</VirtualHost>
root@hosting1:/etc/apache2/suexec#

As you can see, the user has a homedrive of '/home/rootweb', in this homedrive you have the folder called 'public' that is accessible by ftp (for uploading) and http. Then we have a folder 'cgi-bin', here we have the fastcgi php5 wrapper.
The suexec user and group are rootweb.

Currently the wrapper is very easy:
root@hosting1:/home/rootweb/cgi-bin# cat php5-fcgi
#!/bin/sh
PHPRC=/etc/php5/cgi/
export PHPRC
export PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_CHILDREN=8
exec /usr/lib/cgi-bin/php
root@hosting1:/home/rootweb/cgi-bin#

Now as this wrapper is outside of the document root (we cannot put it in, otherwise users are able to modify the php ini's) I should make an exception on suexec security, with suexec-custom I should be able to create a per user file with the user's cgi-bin.
Now the problem I ran into is that suexec-custom only seems to read the www-data user config, even with the above configured suexec user & group rootweb. If I dont create a www-data file I get following error:
[2011-11-14 14:04:40]: User www-data not allowed: Could not open config file /etc/apache2/suexec/www-data
[2011-11-14 14:04:45]: User www-data not allowed: Could not open config file /etc/apache2/suexec/www-data

If I create this www-data config file with following config all works fine and php is running as the user 'rootweb':
root@hosting1:/etc/apache2/suexec# cat www-data
/home/rootweb
cgi-bin
root@hosting1:/etc/apache2/suexec#

But that looks for me not the idea behind this module (for me it looks like a bug) and would force me to put the complete '/home' directory in the file (security issue).

Thanks for reading.

visibility: private → public
Changed in apache2 (Ubuntu):
importance: Undecided → Medium
security vulnerability: yes → no
Revision history for this message
Stefan Fritsch (sf-sfritsch) wrote :

What you want to achieve is out of scope of apache2-suexec-custom. The filename in /etc/apache2/suexec is the name of the run user of apache2, i.e. whatever is specified as 'User' in /etc/apache2/apache2.conf. Or put it differently, that's the user suexec changes from, while SuexecUserGroup specifies the user suexec changes to.

This is described in the suexec man page, but I guess the description could be more clear.

Changed in apache2 (Ubuntu):
status: New → Invalid
Revision history for this message
janl (janl) wrote :

Man page:
       If suexec is called by a user with name 'username', it will look into /etc/apache2/suexec/username for configuration. If the file does not exist, suexec will abort. By creating several config files, you can allow several different apache run users to use suexec.

Oh yes, that could so much clearer.

It would seem a more interesting feature to provide one configuration file for each user given in suexecusergroup instead of one pr. apache server instance.

Documentation needs clearification.

Changed in apache2 (Ubuntu):
status: Invalid → Confirmed
Changed in apache2 (Ubuntu):
assignee: nobody → farhan saleh robleh (farhn)
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

We are sorry, but it looks like this bug fell through the cracks and was forgotten. Since Ubuntu 10.04 is no longer supported, I'm going to mark this issue as "won't fix".

If it's still happening in a supported version of Ubuntu, then please reopen this bug stating the new information. Thanks.

Changed in apache2 (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.