[wp-hackers] Checking getmyuid results in problems?

[Berry Langerak]

Hi.

On 11/15/2010 01:52 PM, Otto wrote:
> The owner of the files must be the same as the current uid of the
> process, not the "apache" user.
>    

First of all: thank you for your (very quick) reply, it's appreciated. I 
may have been a little ambiguous in my previous mail, for which I 
apologise. I'm fully aware that the owner of the files must be the user 
that runs the php-process, which in my case (default apache/php 
installation on ubuntu) is 'www-data'. For a local development 
environment, I consider this to be "good enough", as www-data can 
read/write PHP files.

> On shared webhosts, the php process is often configured to run with the same ownership as the PHP files. This enhances security on a shared hosting solution, since somebody gaining access via the webserver will only gain the credentials of that user, not of the apache user.
>    

I'm using apache2_ mpm_itk to accomplish just this in production. Other 
servers I maintain use suexec for this. Nevertheless, my question sterns 
from the fact that this is unpractical on a development environment, 
where you usually don't change the default Apache user, while you unpack 
Wordpress itself from your own user. So, my files are (by default) owned 
by me, while Apache is executing PHP scripts with 'www-data', which 
doesn't have to be an issue as long as there's no check on uid. Once the 
check is in place, it means that I'll have to log on to my PC as the 
owner of the files, which doesn't have my .vimrc, .zshrc and stuff. Yes, 
there's another option of putting myself in the group that owns the 
file, so I can at least edit them under my own username, and that works 
for me, but it took me a few hours to figure out that that was necessary.

> Your patch (which didn't come through the mailing list) will very
> likely not be accepted into the core because you've changed the owner
> of the files. If you do that, then the original owner no longer has
> access permissions to them, which is unacceptable in a production
> environment.

I do understand where you're coming from, but I'm talking about my 
development environment, where it's everything but unacceptable to leave 
the user to your own uid, instead of creating yet another user for yet 
another project. I've merely replaced the check that getmyuid and 
fileowner has to be equal to a call to is_writable( $context ). That 
means you leave the check to the OS, instead of trying to do the 
servers' work yourself.

>   Furthermore, the files are now owned by the apache user, which will be the credentials of somebody hacking their way in via the webserver process. So you've created a security risk as well. Not changing the owner is important. You can't just throw that away.
>    

I assure you: I haven't imposed a security risk, my PC is in a LAN which 
is not reachable from the internet. Please allow me to state one last 
time: I'm not talking about a production machine, I'm talking about my 
own personal computer, located under my desk. Once I start uploading 
Wordpress to production (or rather, synching it using version control), 
I make sure the uid is correct on the server.

The thing I want to relay is that - although your reasoning seems sound 
for production environments - this non-typical behavior is causing 
headaches for people who develop their software on local development 
machine. If you're not inclined to leave the uid checks to the OS, at 
least make sure the end users know this, so they don't have to wonder 
why Wordpress won't update the plugins, although wordpress is able to 
write to the files.

Cheers,

Berry.