[wp-hackers] Checking getmyuid results in problems?

[Otto]

The owner of the files must be the same as the current uid of the
process, not the "apache" user.

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.

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. 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.

Instead, you should investigate a method of setuid. If you run
mod_php, then the "suphp" package will do the trick. There's also ways
to do setuid of the php process using FastCGI and so forth. This sort
of installation will ensure that the process is running as the owner
of the PHP files, allowing the upgrader to create files with the
correct owner.

-Otto



On Mon, Nov 15, 2010 at 6:39 AM, Berry Langerak <berry at ayavo.nl> wrote:
> 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
>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>