I checked the log files, and found these hits:

In short, it’s mod_security telling me that the text /etc/ triggered rule 950005, which should be protecting our server against malicious attempts to access local files – like the ones in the /etc directory. The access file only showed a POST to /wp/wp-admin/post.php so I had no idea where the /etc/ string was coming from. Maybe some weird hidden Javascript? Maybe something else?

This post narrowed acknowledged it to be related to mod_security and suggested to disable it permanently or just turn it temporarily off while posting. I aim to do better.

The previous post has a wonderful nugget of enlightenment about prioritizing services on Linux, and suggested a couple of changes to the Linux configuration files – most of which are located in.. the /etc/ folder. In short, I triggered mod_security rule 950005 by posting data containing /etc/.

If you ever plan to cover issues related to deployment and administration of operating system in the Unix family, this rule absolutely has got to go. Obviously it’s written with the best of intentions, but as it is doesn’t work and should be disabled.

Avoid messing with /etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf and just disable the specific rules in /etc/httpd/conf.d/mod_security.conf by adding this:

Aside from being a website developer, I’m also a paranoid system administrator. One of the first thing I add to my login scripts, is umask 077 – the command that sets the permission mask for newly created files. Setting this to 077 prevents anyone but the current user from being granted any rights – read, write or execution. It’s a sane thing to do, but unfortunately a lot of scripts fail to explicitly grant access to other users, especially when installing RPM packages or – in this case – running VMWare after a kernel upgrade to build new VMWare-specific kernel modules.

In this specific case, VMWare kernel modules were built by the root user, and ended up in /lib/modules/2.6.27.19-170.2.35.fc10.x86_64/misc/ which was created by the build process. Read permissions were not explicitly granted to everyone, so when running vmware as a mortal user, it was unable to actually read and verify the newly built kernel modules. The natural response to the user wasn’t “Unable to read kernel module files”, but instead “You need to build kernel modules for your specific kernel”. Makes a lot of sense, eh?

Manually granting read and execution rights on the /misc directory and the files in it fixed the issue.