Virtualmin 3.96 mod_php forced off (how to revert to old behavior)

I have various installs of Roundcube and Phpmyadmin on hundreds of machines, and this update has just disabled all of them.

I have removed the “php_admin_value engine Off” from the httpd.conf file and this has fixed it temporarily.

I need to know how to stop this from being reapplied (if that would happen) and how to stop it from being added to newly created virtual servers.

I checked in the default Apache configuration in the server template and this isn’t even mentioned there.

What PHP execution mode do you have set for these domains? If it is CGI or fcgid mode, then Virtualmin’s disable of mod_php shouldn’t have any effect.

Also, do you have a sharded install of phpMyAdmin, perhaps using a symlink from each domain’s directory?

All domains are using fcgid, the PHP files in each domain work correctly, I use mod_php for Roundcube/Phpmyadmin. This is the easiest to support and keep updated on all of these machines.

So how did you set that up exactly? Do you have your domain configured to use mod_php just for one directory?

I just used the default configuration for new virtual sites (all sites are using cfgid the default), I put a new configuration file in /etc/httpd/conf.d with this in it.

Nothing had to be done to any site at all, I just had to put the roundcube/phpmyadmin files in their directory and the configuration in /etc/httpd/conf.d and it worked great.

AddHandler php5-script .php
AddType text/html .php

to turn on mod_php for that directory. It worked wonderfully, it was available for all sites, and it is easy to maintain and update on multiple servers.

Could you post the file that you created in /etc/httpd/conf.d ?

# Roundcube 0.8.x for Virtualmin # Updated 08.27.2012 lp alias /webmail /usr/sw0/roundcube Options -Indexes AllowOverride All Allow from all AddHandler php5-script .php AddType text/html .php I tried adding a "php_admin_value engine on" but that did not work.

Ok, the problem here is that mod_php is disabled for the domain (via the setting in the virtualhost blocks), but the roundcube alias will try to use mod_php to execute PHP scripts.

You can delete the php_admin_value Engine off directive from all your domains to fix the issue. However, this does open you up to an exploit by un-trusted domain owners.

Alternately, you can use Virtualmin to install roundcube into each domain separately.

Installing a separate copy for each domain is not a option. That would be a nightmare to support not to mention needing a database for each site.

There needs to be a option to stop this line from being added to the httpd.conf file. Or I need a way to counteract it.

I have a bit of perl that will wipe that from the httpd.conf file, Will it come back when changes are made to the domain? And I need to stop it from being added for new domains as well.

What file or configuration setting is making this “php_admin_value engine off” go in the configuration file?

Wait a few days, and we will release a Virtualmin update that makes it optional if this php_admin_value directive is added or not.

Excellent, Thank you!

@lp86 I am jus curious.

Could you explain why you are not concerned about the security vulnerability? Maybe you have a different way of dealing with it?

Hi JamieCameron or others.

Same problem here, I just upgraded to virtualmin 3.96, and now I cant get access to the phpmyadmin

when I try to access, the browser ask what to do with the index.php file ???

How and WHERE can I correct this…

I`m in the middle of some db corrections, and now I´m stuck !

Best regards

  • Open "/etc/httpd/conf/httpd.conf" with a editor, vi/nano/etc
  • Remove all instances of "php_admin_value engine Off"
  • Then restart Apache "/sbin/service httpd restart"


i am having the same problem but can’t locate /etc/httpd/conf/httpd.conf

i have no httpd directory in etc?

my site is down but emails working and its been like this since friday! HELP!!

cheers lenka

If you are on Debian or Ubuntu, the config files are in /etc/apache2/sites-enabled

i only have:

php5 (directory)

in my etc directory?

Another way to do this: Use a central installation of RoundCube on its own ghost in a Virtualmin vserver. Add Apache mod_rewrite redirects to that to all domains. I use this:

Http://webmail.customerdomain.tld ->

I think this is probably the cleanest way to do this.


Just discovered the same problem here, with these additionnal infos:

I have a bunch of sites, declared as virtual hosts and using fcgid, they do work fine with “Engine Off”.

But on that same VPS, I have 9 sites sharing a common install of “spip” CMS: just one install of the core of the CMS in the master-site folder, one database for each domain. So the CMS is installed in the master-site “public_html”, where I have a “sites” folder containing specifics for each slave-site (like a Drupal multi-site).
Then each slave-site (declared as a virtual host to be able to have mail) has a Website redirect from its “/” to “/home/master/public_html” …

The 8 slave-site have the same symptoms where Firefox asks what to do with the php file (like when php is not interpreted) … The master-site does not have that problem !!
After many many tests, we finally found out that we could fix the problem by just removing the “Engine Off” setting for each of the 8 slaves sites, we did this from Virtualmin (Webmin->servers->Apache->select a virtual server->PHP->Config values for PHP on top).

I’m kind of annoyed knowing now that this a security issue … do you have any references about it ? is this major or just borderline ?

And yes, I’m also afraid of having to do this after each update of virtualmin … could update at least not change the existing settings ?


This is a major security issue (like the other issue that was fixed followsymlinks). For example if you have untrusted sites (e.g. a site that could be easily hacked, but you thought the site was “isolated”) or untrusted users (“who could be curious enough to peek into others config files”).

Some also argue, that this well known (and very easy to exploit) security issue has been there for a long time, so that if somebody on your server were interested to collect your config passwords etc they probably did already :slight_smile: