[wp-hackers] Checking getmyuid results in problems?

[Berry Langerak]

Hi.

Here's my first post to the hacker mailing list. I've spent half my day 
helping out a co-worker who has been experiencing problems with WPAU, as 
a click on "upgrade automatically" on the Plug-ins page would result in 
a form asking for FTP credentials and servername, and there's no FTP 
server running on his localhost. I've been in the business for quite a 
while, contributing to other projects, and earning my paycheck by 
writing applications for customers, so I'm rather well-known with 
permissions on Unix. Obviously, my first remark was: make sure that the 
Apache user can write to the directories and files that wordpress has 
installed.

So he did: his username was his local username (e.g. 'berry'), the group 
was 'www-data', and the filepermissions were 0775, meaning the group 
'www-data' was able to write to the files. Please do note that there was 
at that time no problem to write wp-config.php from the installation 
wizard, and it was also possible to edit plugins with the embedded 
plugins editor. However, there was still no possibility to update the 
plugins.

Now, having a <user>:www-data owner on files isn't that unusual: it's a 
rather common way of making sure that your own user as well as the 
apache user can write to the files. It's important to stress that 
development doesn't happen on a remote FTP server, as we're a software 
company, we develop on development machines and we *never* develop on 
production servers. A call to is_writable( ) would result in true, so I 
figured it ought to work. It didn't. After debugging for quite some 
time, I found a line in the wordpress core which contained the following 
code:

     if ( getmyuid() == @fileowner($temp_file_name) ).

It seems the Apache user *must* be the owner of the files, before 
Wordpress WPAU will even try to update the plugins, which is unexpected 
behaviour, from my point of view. My logic is that if the user is able 
to write to files, that would be enough to write to files. In the case 
of WPAU, this isn't true. While searching though the bug tracker, I've 
found several previous tickets about this exact problem, such as #8400 
and #10424.

In #8400, DD32 responds with 'wontfix'. In #10424, DD32 responds to the 
ticket with an explanation which makes sense, but mostly for shared 
webhosting. Now, I'm sure that most users of Wordpress have the 
application hosted on shared webhosting, and they never have a local 
copy to develop in. However, the people that write code for a living 
usually have multiple environments to write, test and run their code on. 
In our case, developing and the first testing happens on a local 
machine. We write, debug and test our code using an IDE. That makes it 
very awkward for www-data to be the owner of the files that wordpress 
should edit, because you have to either change the owner to 
www-data:<user> and chmod to 077x, or run your IDE by using su - 
www-data, which is obviously a workaround I dislike.

Now, I wouldn't mind the getmyuid to fileowner check much if that was 
well-documented and consistent, but it seems that it's not. You see, 
wp-config.php was written after the installation-wizard without 
performing the check, and I can edit the plugins using the embedded 
editor, without the check being performed. It's just the updating of 
plugins that doesn't seem to work. That's the reason I assumed I had an 
issue with the plugin files not being writable, while they actually were 
writable.

I've written a patch (attached) to use is_writable instead of getmyuid 
and fileowner, which makes the whole installation work like a charm. Am 
I wrong in assuming that the files being writable should be the only 
check necessary, or is there some logic that I am still overlooking, 
which makes the check make sense? Yes, a lot of (shared) hosting servers 
are not that well configured. Yes, once you run Apache as another user 
than the owner, this will result in a different owner upon writing new 
files. But isn't this only relevant in production and shouldn't that be 
fixed by the webhoster, and not by the software?


Cheers,

Berry.

Met vriendelijke groet,

Berry Langerak.
-- 
Ayavo BV
Tel. 013-5810450
Fax. 013-5810454
Mob. 06-10110635