WordPress Automatic Update Bug

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.

Tags: ,

3 Responses to “WordPress Automatic Update Bug”

  1. LornaJane Says:

    Thanks for the update – I knew it was ownership but also thought it was a bit odd! Let us know how you get on with that bug?

  2. Tony Jennings Says:

    Hi,
    thanks for the fix to the wordpress upgrade problem – you saved me lots of time!

    One of my clients had exactly this issue where the usernames didn’t match PLUS unless her folders are at 777, the writes fail as well (I haven’t seen either of these on any other server). I don’t like being at 777, that’s pretty scary!

    Great site – strange hair styles girl!

  3. Rawn Says:

    Keep in mind anytime you find anything this obviously wrong, the WP team is always already aware of it and refusing to fix it. They have a tendency to dig in their heels about their poor choices.

    You might have better luck seeing if it’s possible to override their code via a plugin. They might agree to assist with that by adding any needed hooks.

Leave a Reply