Posts Tagged ‘Bug’

WordPress Automatic Update Bug – Follow Up

Thursday, July 16th, 2009

The bug I raised on WordPress yesterday as documented in this blog post has been closed as a ‘duplicate’.

Looking through the bugs about a month ago someone else raised a very similar bug report and proposed a very similar solution. That bug report was closed with ‘wontfix’. The basic comment is that (a) they know about it; (b) they think changing the behaviour will break shared hosting; (c) group write support is not supported in WordPress anyway.

The comments in the bug do confirm something I spotted yesterday when looking at the latest release revision of wp-admin/includes/file.php which is that you can completely over-ride the write checking mechanism in WordPress 2.8 and above if you define the constant FS_METHOD to be ‘direct’. A bit hacky but useful. It means I can use decent permissions and still use auto-update. Time to upgrade to 2.8.1 I think.

WordPress Automatic Update Bug

Wednesday, July 15th, 2009

LornaJane wrote an article on her blog about WordPress automatic update asking for FTP. As I’ve been having problems with the automatic update too and since I also don’t want to install FTP I changed permissions as she suggested. Unfortunately, even with ‘other’ (world) write permissions, I was still being asked for FTP details. After some discussion on IRC it turns out that not only do you need the right permissions but you need the files with the right owner i.e. the Apache process. This didn’t seem right. Why an earth do you need the right ownership if you can write anyway. Also if you have to have the files owned by the Apache process any scripting running on the server can access and change the files. Its a security risk. So I decided to dig deeper.

Grepping the WordPress source for the text line ‘There was an error connecting to the server, Please verify the settings are correct.’ showed me the relevant code is in wp-admin/includes/file.php. The function that requests the FTP details is request_filesystem_credentials(). This function is called if get_filesystem_method() returns a method other than ‘direct’. It seemed that get_filesystem_method() was at fault. The relevant code snippet is below.

        $method = false;
        if( function_exists('getmyuid') && function_exists('fileowner') ){
                $temp_file = wp_tempnam();
                if ( getmyuid() == fileowner($temp_file) )
                        $method = 'direct';
                unlink($temp_file);
        }

Examining the function it seems that it tries to creates temporary file (typically in wp-content) and if successful compares the ownership of that file with the process. If equivalent it decides that it can use ‘direct’ mode. The problem is it uses getmyuid() which according to the documentation returns the owner of the file that called the function and not the owner of the process running the code. I.e. the owner of wp-admin/includes/file.php. It doesn’t matter who the owner of the apache process is. There is another function
posix_getuid() which returns the process owner. So I have modified the get_filesystem_method() function as follows:

        $method = false;
        if( function_exists('posix_getuid') && function_exists('fileowner') ){
                $temp_file = wp_tempnam();
                if ( posix_getuid() == fileowner($temp_file) )
                        $method = 'direct';
                unlink($temp_file);
        } else if( function_exists('getmyuid') && function_exists('fileowner') ){
                $temp_file = wp_tempnam();
                if ( getmyuid() == fileowner($temp_file) )
                        $method = 'direct';
                unlink($temp_file);
        }

I.e it checks to see if posix_getuid() is supported and if it is it uses that instead. This allows me to have my WordPress files owned by a different owner than the apache process. I have set the wp-content to a member of a group containing the apache process owner and made them group writeable. As long as apache can write the temp file WordPress can use automatic update. This is still some what insecure but better than having all the WordPress files either owner by the apache process or world writeable.

Note that I am currently running WordPress 2.7.1. Looking at WordPress 2.8.1 the get_filesystem_method() function has changed but not significantly. I am raising a bug.