I have this config on my Virtualmin:
most Virtual servers are on FCGI (except some testing ones). There is common alias /webmail to /usr/local/share/roundcube, where is shared roundcube for all domains (just to maintain them at once).
I have upgraded to 3.96. There is a new security feature, which disables mod_php for fcgi-based websites. Because the roundcube is outside of the DocumentRoot, it is not covered by FCGI handler, but it is covered with php engine Off, so no php interpretation is done and the result is that the source code is printed as plain text! I think this could be considered as a bug.
And on the other hand - I want to keep the shared roundcube. How to solve it the most effective way? I made up few proposals:
remove php_admin_engine Off from all my virtual servers. - Nice, but what about the new ones?
add FCGI directives for the roundcube directory or <Location /webmail> to all domains and add this directive to the Template. But if I make a new server with mod_php5 setup, webmail will be still on FCGI.
redirect all /webmail from all domains to a single domain, which would be correctly set up for local roundcube - this is what the customer don’t want - wants to see the own domain on all webmails
install own roundcube to every domain - Phuuuuuy, not this way!
Somehow disable disabling php_mod - in the next version?
Of your listed options, I personally use option 3.
None of my users ever complained that they get forwarded in the browser from “http://webmail.customerdomain.de” to “https://webmail.hosterdomain.de”.
Option 5 is already done too by the way; Virtualmin 3.97 made the security fix thing optional. It’s not recommended to not apply the fixes though, except all your users are 100% trustworthy and 100% hacker-proof.
Another option would be a reverse proxy. That way the browser URL bar still shows the customerdomain, while internally your one-for-all Roundcube domain is fetched.
1) remove php_admin_engine Off from all my virtual servers. - Nice, but what about the new ones?
5) Somehow disable disabling php_mod - in the next version?
Well, those settings prevent a pretty big security problem; I wouldn’t recommend removing those if at all possible.
3) redirect all /webmail from all domains to a single domain, which would be correctly set up for local roundcube - this is what the customer don’t want - wants to see the own domain on all webmails
I would highly recommend this option, actually
We suggest serving files from within a Virtual Server on your system, from a defined DocumentRoot.
And with something like the above – you could setup a central Virtual Server for hosting RoundCube.
Your users could still access it using webmail.theirdomain.tld, which would then redirect to your central installation.
And then, if you like, your central install could be setup with a commercial SSL cert (NameCheap has these for $9, and StartSSL even offers them for free). That would keep everything encrypted, and not produce a warning message.
Thanks Eric for sharing my opinion! And yep indeed, I have a StartSSL cert on my webmail domain.
I understand you all, I understand the ssl purposes too (I am not a beginner) but my situation is that I am not the hoster, I am just the administrator for the hoster and he wants to have all webmails in the original domains. So I can vote for 3, but he has the veto. Finaly I made it with (2) (pushed some directives into virtualservers by a sed script) and let’s have no php_mod-based websites.
I made up other option:
- with every new server “domain.com” there should be a new subserver (ServerAlias) under central webmail server, which name would be webmail.domain.com. - Is it possible to trigger it somehow automaticaly? But this will not work with ssl.
I have installed 3.97 but I can’t find such option - where can I find the possiblility for disabling it? In changelog there is something like it will give a warning for it, but nothing about canceling the disable feature neither in new virtual servers nor in the existing ones.
And finaly - I am surprised that nobody noticed that the source code can be revealed with php_mod off! I think it may be a bigger problem then execution of another customer’s code.
There is a function to create an alias automatically with new virtual servers. Check out the server templates, section “Virtual server creation”.
If you need to do more general things, you can also have it execute scripts when servers/users are created/modified. Check Virtualmin config, section “Actions upon server and user creation”.
The documentation section on this website has extensive information on how to make such scripts and what placeholders you can use.
The other purpose is:
7) Set up mod_proxy and set up proxy for every domain, which would connect to roundcube on master webmail server. A bit more CPU consumpting, but pretty clean solution I think.
But still - No reaction on fact, that php SOURCE CODE REVEAL is possible? Php scripts often have passwords inside (and bugs of course).