PHP execution mode and file permissions


We have a few Wordpress sites which were installed using the install script. Each was installed into a virtual server which was running with the FCGI PHP exec.

Due to some memory issues, and FCGI seeming to keep old processes lingering around, I had to switch those sites to using the mod_php exec mode instead. This works fine for executing PHP code on behalf of Apache, but when it comes to modyfing anything through Wordpress, it’s now not possible due to file permission errors. There is no write access for Apache within /home/domain/public_html/.

The issue here is that all files & folders inside public_html belong to site1:site1, whereas mod_php would seem to prefer if the files belonged to site1:apache (assuming a 664 file permission and 775 directory permission).

Is there a foolproof way to switch execution modes for virtual servers without running into file permission issues like this?

We have Virtualmin Pro on CentOS 5.

Thanks, in anticipation…


There unfortunately isn’t a foolproof way of handling that…

Note that FCGID intentionally keeps old processes around, that’s how it handles the caching which speeds up page access.

If FCGID isn’t working as desired though, you may want to explore CGI mode, which is more secure, and should be simpler to get working.

Otherwise – when using mod_php, most people end up needing to set certain files and directories to be world writable, since the Apache user needs to be able to write to it. Which ones need to be set that way depends on the application in question.


Thanks for your response.

Perhaps you could clarify this for me…

If the Virtual Server is set to use mod_php when created and then a Wordpress install script is run, the files are written to public_html with ownership of domainuser:domaingroup, rather than domainuser:apache.

Is this the expected behaviour, even though it’s known that the virtual server is running with mod_php and would therefore suffer from the potential permission issue?


I’m talking to Jamie about having that handled automatically – it’s a matter of determining which files and directories need to have the permissions changed.

Remember though that this is really really really insecure :slight_smile:

It means that anyone else on your server who has a website can modify your WordPress installation.

We highly recommend against such a setup, unless all the users on your server are trusted.

If any users on your server aren’t trusted, we’d definitely suggest using either FCGID or CGI, which both execute PHP with the permissions of the Virtual Server owner, rather than that of the Apache process.

But, I’ll go over the details of all this with Jamie to see if we could better support using mod_php for folks who prefer to use that particular mode.


Well, actually…

I don’t actually prefer using mod_php, I prefer fcgid in an ideal world. But with a large number of wordpress installs on a single box, the memory utlisation is too high. So we’re forced into looking at running in mod_php or CGI mode.

Given the permissions issues with moving from fcgid to mod_php, I thought I’d try using CGI instead. But we’re still getting the problem where Wordpress loses some key functionality in any mode other than fcgid.

For example, you cannot create a new page/post when running in cgi mode but you can in fcgid. I can’t fathom why this is yet, as I have chown’d all files & directories to “domainuser:domaingrp” and modified the perms as recommended on Wordpress’s site.

Any advice or pointers gratefully received…


FWIW - I’ve just tested creating a new virtual server with cgi as the default PHP execution mode. Then I ran the Wordpress install script, logged into this new Wordpress admin area and have the same problem.

There would appear to be something “not right” with this on anything other than fcgid.

Is this bug-worthy or not a Virtualmin issue? (i.e. it’s a Wordpress issue)



Hmm, that sounds like an odd issue!

I use CGI by default on my own server, and I don’t have any WordPress problems such as what you’re describing.

In theory, WordPress should run great under CGI :slight_smile:

It should run under mod_php as well, though there is the potential for some files or dirs to need additional permissions.

But that’s not the case with CGI, CGI runs with the permission of the Virtual Server owner.

So maybe we should back up one step –

What error(s) are you seeing when running in CGI mode?

And what shows up in the logs in $HOME/logs/error_log?

The default ownership and permissions should work correctly – one thing you may want to do is to reset those… you can do that by going into Limits and Validation -> Validate Virtual Servers -> Fix Permissions, and have it reset the permissions for the domain that you’re having trouble with now.

Also, which Linux distribution and version is it that you’re using there? Thanks!


Ok, I followed the steps through to Fix Permissions, found my test site (with WP installed), and hit the button…

Unfortunately, the symptoms persist. The symptoms are that, in WP in the “Add New Page” page, the box to the top right where you’d normally have the Publish and Save Draft buttons is totally empty - it’s just a thick, grey dashed-line border with nothing in it.

It’s also impossible to edit themes. You click to Appearance > Themes, then click “Customize” and … nothing. Blank screen. If I set the execution mode back from CGI wrapper to fcgid, and refresh my browser, hey presto! The theme editor loads in my browser.

So, I was about to say “And the Apache error log is totally clear, apart from a missing favicon”… but there is an error present:

PHP Fatal error: Call to a member function theme() on a non-object in /home/domain/public_html/wp-admin/customize.php on line 60, referer:

Finally - we have something! And this error is only logged when running in CGI Wrapper mode, not in fcgid mode.

It looks like one or other mode is doing something right/wrong.

The operating system is CentOS 5, x86_64, with PHP 5.2.10 installed from the CentOS testing repo, replacing the OS’s stock PHP v.5.1.6.

Perhaps this is an issue with that particular PHP version when running in CGI mode?

I’ve Googled quickly for related issues - nothing yet…


What if you edit $HOME/etc/php.ini, and set cgi.fix_pathinfo to “0” – does that help with the issue you’re seeing?


Yes, yes it does!

So basically Wordpress is, shall we say, being ‘creative’ wrt the CGI spec and trying to include/require stuff using an older-style path convention. Nice… :wink:

[ ]

Ok, thanks for helping with this.

I’ve created /etc/php-cgifix.ini which includes this fix, and I’ve edited the default Virtual Server template, modifying the “Template PHP 5 configuration file” setting in the “Apache Website” section to copy /etc/php-cgifix.ini when new virtual servers are created.

I’m kinda assuming this is a safe approach given that you put the option there to do this… :smiley:

Many thanks.

Yup, it’s no problem to do that.

The new Virtualmin version that’s coming out soon will have a better fix for that applied automatically to all new Virtual Servers, but that php.ini tweak is a great option in the meantime.


Cool, sounds good.

I’ll try to keep up to date with your release notes and remove my tweak when the new version is out.

Thanks again for your assistance.