Wordpress upgrade process removed executable bits on .php files and so broke Wordpress

[gerv]

I just upgraded from 3.2 to 3.3.1 on my shared hosting box (hosted by ​http://www.mythic-beasts.com). This uses suexec, and so .php scripts need to have executable permissions otherwise it won't execute them. I am told that many secure multi-user setups work like this.

My original install had the PHP scripts set as executable, but I did the upgrade (via the web GUI) and suddenly I got 500 Server Errors everywhere. I had to chmod all .php files back to executable before my blog would work again.

Wordpress should check the permissions on .php files before upgrading and preserve them across the upgrade.

Gerv

I have never heard of a non-executable file requiring the executable bit to be parsed by the server, Likewise, In the last few years, this is the first report of such a server configuration ever being mentioned in the tens of millions of installs.. and there's been some really weird edge-case setups that some people are using.

I say that the php files should not require the executable bit, due to the files not being executed directly themselves, instead, Apache (or whatever server software is in use) would pass the .php files to it's handler, presumably, a PHP CGI running in suexec mode, which itself, has the executable bit set as it's the process that's executed (as the server can actually execute the binary file, rather than the .php text file which is meaningless to anything but a PHP Binary)

That being said, WordPress currently writes files as 644, which is a "safe" permission set, which is more relaxed than may be needed by some servers, any tighter and some servers refuse, more relaxed, and some servers complain, and yet, we can't trust the existing file permissions in many cases due to them being set incorrectly to start with (world writable for example).

In your case, You can add the following define to your wp-config.php file to avoid this issue with core upgrades, and plugin/theme installs/upgrades:

define( 'FS_CHMOD_FILE', 0750 );

(I assume it's 0755 you need, but you might also need to use 754 or 755 - but your host should be aware of this - note, it must be specified with the leading zero, and must not be in a quoted string, exactly as above)

---

For reference, I've found ​this old article (scroll down to suexec at the bottom) on a configuration which requires the .php to be set to executable mode, but it also requires a Hashbang to be added to each file to specify the interprator, or, through a ​little known feature of the linux kernel to specify parsers for specific file types.

Whoa, wait a second :-) Give us more than a few minutes to argue the case. I've asked the guy who runs our hosting company to drop in and testify to how common this is. If he doesn't, then you can close it. :-)

Gerv

Sure.

apache-2.2.21/support/suexec.c:

   580       * Error out if the program is not executable for the user.
   581       * Otherwise, she won't find any error in the logs except for
   582       * "[error] Premature end of script headers: ..."
   583       */
   584      if (!(prg_info.st_mode & S_IXUSR)) {
   585          log_err("file has no execute permission: (%s/%s)\n", cwd, cmd);
   586          exit(121);
   587      }

In combination with binfmt (which may be little known, but is supported by all the major Linux distros), mod_suexec provides a way for an apache-based hosting service to run php scripts under the uid of the website owner.

#t

Yep, that's what my host is using.

Gerv