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

[Simon Prosser]

If your on debian, its pretty easy to switch to suPHP which will use
your username/group
Its not as fast as mod_php, or alternatively there is mpm_itk in
debian, which has the speed and the shared memory of mod_php and still
uses usernames.
I used to use it before switching to gentoo.

On 13 July 2011 18:03, Otto <otto at ottodestruct.com> wrote:
> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
My Blog: http://www.pross.org.uk/
Plugins : http://www.pross.org.uk/plugins/
Themes: http://wordpress.org/extend/themes/profile/pross