[Pkg-dspam-misc] Bug#638289: dspam-webfrontend: Using apache2-dspam.conf make other apache2 depending packages unusable

[mahashakti89]

On Thu, Aug 18, 2011 at 03:51:38PM +0200, Julien Valroff wrote:
>Le jeudi 18 août 2011 à 11:37:48 (+0200 CEST), mahashakti89 at orange.fr a écrit :
>> Package: dspam-webfrontend
>> Version: 3.10.1+dfsg-2
>> Severity: normal
>> Tags: sid
>>
>> Hi,
>>
>> Installing the dspam-webfrontend package make it impossible to access to
>> the web interface of other apache2 depending packages like backuppc or
>> dpkg-www which were running O.K. before. For theses packages I get an
>> Internal Server error , Error 500. Looking in /var/log/apache2/suexec.log
>> gives following error message :
>>
>> [2011-08-18 11:30:13]: uid: (110/dspam) gid: (113/dspam) cmd: index.cgi
>> [2011-08-18 11:30:13]: command not in docroot (/usr/share/backuppc/cgi-bin/index.cgi)
>> [2011-08-18 11:30:39]: uid: (110/dspam) gid: (113/dspam) cmd: dpkg
>> [2011-08-18 11:30:39]: command not in docroot (/usr/lib/cgi-bin/dpkg)
>>
>> The only way I found till then was to comment out  the SuexecUserGroup
>> line in /etc/apache2/conf.d/dspam.conf but  ... it is not a solution .
>
>The SuexecUserGroup directive should indeed be located in a VirtualHost
>block to restrict its effect to this virtual host.
>
>Would you please test the attached apache configuration snippet and tell me
>what you think of it?
>
>It creates a virtual host listening on port 8024, only reachable from the
>local machine.
>
>Cheers,
>Julien
>
>-- 

Hi,Julien


Thanks for the code, it's now working, I was searching in this direction
but my skills in apache configuration are not so great !
Dspam-webfrontend, dpkg-www and backuppc can now be accessed without
disabling suexec in /etc/apache2/conf.d/dspam.conf.

Thanks for your work


mahashakti89



>  .''`.   Julien Valroff ~ <julien at kirya.net> ~ <julien at debian.org>
> : :'  :  Debian Developer & Free software contributor
> `. `'`   http://www.kirya.net/
>   `-     4096R/ E1D8 5796 8214 4687 E416  948C 859F EF67 258E 26B1

># Dspam example website configuration for Apache 2
>#
># Use htpasswd to create /etc/dspam/passwd and add a system username.
># The password should not be the same as the user's system password.
># # htpasswd -c /etc/dspam/passwd <username>
># # chown root.www-data /etc/dspam/passwd && chmod 640 /etc/dspam/passwd
>#
># Make sure the suexec module is installed and loaded:
># # apt-get install apache2-suexec
># # a2enmod suexec
>#
># Install this file in Apache configuration directory:
># # cp /usr/share/doc/dspam-webfrontend/examples/apache2.conf \
>#       /etc/apache2/conf.d/dspam
>#
># Then visit http://127.0.0.1:8024 and log in.
>#
># Add the admin username to /etc/dspam/admins, which will enable the
># 'Administrative Suite' tab and functionality for that person.
>
>Listen 8024
>
><Directory /var/www/dspam/>
>    # This makes the /dspam directory unavailable from the default virtual host
>    Order deny,allow
>    Deny from all
></Directory>
>
><VirtualHost *:8024>
>    DocumentRoot /var/www/dspam/
>    SuexecUserGroup dspam dspam
>
>    Alias /usr/share/dspam /usr/share/dspam/
>
>    <Directory /var/www/dspam/>
>        Addhandler cgi-script .cgi
>        DirectoryIndex dspam.cgi
>
>        Options +ExecCGI +MultiViews -Indexes
>
>        AllowOverride None
>
>        Order deny,allow
>        Deny from all
>
>        # This makes the DSPAM WebUI only available from the local machine
>	# You may obviously want to add other IP adresses (local network etc.)
>        # to the following line
>        Allow from 127.0.0.0/255.0.0.0 ::1/128
>
>        AuthType Basic
>        AuthName "DSPAM Control Center"
>        AuthUserFile /etc/dspam/passwd
>        Require valid-user
>    </Directory>
>
>    <Directory /usr/share/dspam/>
>        Options -Indexes
>        AllowOverride None
>    </Directory>
></VirtualHost>
>
># The above configuration is provided only as an example.  For serious work
># over the internet, it should be set up as a proper VirtualHost and SSL
># should be used to protect the user's credentials.  If the site has many
># users, consider using one of the db-based authentication methods,
># e.g. mod_auth_mysql.

On Thu, Aug 18, 2011 at 03:51:38PM +0200, Julien Valroff wrote: