Protecting .htaccess from WP Better Security

I previously mentioned my .htaccess file got corrupted and I guessed it was the fault of an addon.  I have since figured out it’s WP Better Security doing it.  The plugin has been very useful so rather than abandoning it, I looked into how to get around the problem.  The biggest problem is when the hidden file is corrupted, it brings the site down and I’m not immediately aware of it since I only check it every now and then.  Google’s bot will eventually send me an email after a certain number of failed attempts to access the site so I’m not in the dark for too long about the problem.  That’s one of the benefits Google webmaster tools includes.

The corruption is caused when two separate threads attempt to modify the file at the same time.  In my situation, it’s caused when the login bots attempt to guess passwords at the same time, either from the same IP address or from more than one IP address.

My first attempt to fix it, which I knew was not really a solution but did increase the odds of preventing it, was to introduce a random wait time before the file could be accessed.  That helped a lot but as with anything random, it’s still possible to get the same, or nearly the same, value.  Because of that, the file still got corrupted occasionally.

Today I noticed 404 errors in the logs.  The .htaccess file was corrupted in such a way that nothing except the administration pages worked.  It took me a little bit of time to figure out that the .htaccess file was the cause but sure enough, when I replaced it with a backup copy, all was well again.  That made me think it’s time to permanently solve the problem.

The solution I thought of first is a concept I learned in an Operating Systems class.  It’s called a mutual exclusion lock, or mutex lock.  Using such a lock guarantees no two threads or processes can access the contained section, known as the critical section, at the same time.  It’s wise to keep the area as small as possible to minimize performance impacts.

I found reference to it through a Google search but when I tried to place the appropriate statements in, I found it didn’t seem to work.  I’m not clear as to whether it’s currently implemented natively in PHP or not but I don’t think it is.  Since I couldn’t get it to work, I needed to come up with a different solution.

More searching on Google (and Bing) led me to the keyword flock, or file lock.  That method seems to have the same properties of what I’m looking for.

I found in WP Better Security, the function to write to the file is called writehtaccess() and is contained in the file common.php.  I added the following a bit after the file system pointer is received but also after the statements that take care of error handling are passed:

if (flock($f, LOCK_EX) == false)
{
   $sleepTime = rand(100000, 500000);
   while (flock($f, LOCK_EX) == false)
   {
      usleep ($sleepTime);
   }
}

That allows the calling thread to sleep for a random time between .1 and .5 seconds before trying again if the first try to gain the lock fails.  It might not be necessary to calculate a random time for the wait but I threw it in there for good measure.  Just before the file close statement, I added:

flock($f, LOCK_UN);

That statement releases the lock.  Hopefully that will be the end of the corruption issues I’ve been experiencing.  If not, it’s back to the drawing board or further research into why my implementation isn’t working.

Edit: It didn’t work.  I made another post outlining my revised solution.