[wp-hackers] File management permission/owner best practices

[Otto]

On Wed, Jul 13, 2011 at 11:11 AM, Philip Walton <philip at philipwalton.com> wrote:
> I'm running WordPress on my own server (Debian 6.0) that I have ssh and root
> access to. My web server runs as www-data. I'd like to set up all the files
> in my WordPress directory to user/group philip/www-data, but I'm
> encountering problems.
>
> According to this site
> <http://www.chrisabernethy.com/why-wordpress-asks-connection-info/>, before
> WordPress download a plugin/theme it "creates a temporary file and confirms
> that the file just created is owned by the same user that /owns the script
> currently being run/". in this case |wp-admin/plugin-install.php|. In my
> case the file it creates is owned by www-data, so it fails because
> |wp-admin/plugin-install.php |is owned by philip.
>
> I could do "chown -R www-data:www-data .", but then I run into issues when
> trying to do things like rsync because I connect via ssh as philip. I use
> rsync to upload my own themes and plugins all the time, and it's annoying to
> constantly have to change the file owners for these types of things.
>
> What do other people do to overcome this? What are the recommended best
> practices for those who don't want to use FTP?
>
> p.s. I'm somewhat new to linux, so if I've got it totally backward, please
> set me straight.

Yes, basically you're looking at this from the wrong perspective.
There's two cases to consider.

One is a dedicated webserver, where there is only one user of the box
and its websites. In this case, you don't really want the webserver to
be the owner of the files, because if there is any sort of hacker who
gains access via the webserver, then he will end up with the
credentials of that server. So if somebody breaches the code, then
they end up being the "www-data" user. If www-data has access, then
now your hacker has the same access. If www-data can rewrite your
files directly, then so can your hacker. So for security reasons, you
*need* to have that FTP data input there.

In the case of a shared server, you have multiple users all sharing
the same webserver. Each user has different credentials. In this case,
a hacker who gained access as www-data would now have access to a much
wider range of accounts and websites. However, in such a scenario,
users are more likely to have more open permissions schemes, such as
777 uploads directories and the like. This makes these users targets
even for the hacker with www-data credentials, giving him backdoor
access into those other sites.

In such a case, many shared servers use a method called "setuid" or
similar. Essentially, this is a modified way to run PHP such that,
when the webserver process calls the PHP executable, a script or other
code changes the user id of the running process to be the same as the
owner of the PHP script. So instead of PHP running as "www-data", it
runs my files as "otto". This has two effects: a) anybody hacking into
my website gets my credentials, but that protects other users of the
machine (since I won't have access outside my directories) and it
eliminates the need for sites to run with open permissions schemes
like 777 and such and b) if the process creates a file, it creates it
with my user id, thus allowing the direct upgrade method to work and
eliminating my need to input FTP credentials.

The bottom line is that you shouldn't be changing file ownership in
order to use the direct upgrade method at all. That will always lead
to poorer security. If you're on a testing machine or just totally
unconcerned about security issues, you can pre-define the FTP
credentials by using defines in your wp-config.php file. Use FTP_HOST,
FTP_USER, and FTP_PASS. If you are using ftp over ssh, you can also
define FTP_SSH, FTP_PUBKEY and FTP_PRIKEY as needed. For ftp over ssl,
define FTP_SSL. You can find all these in wp-admin/includes/file.php.

-Otto