That chown looks super suspect. Usually you wouldn't want the webserver to have write access to the web application it is executing; that's how you get backdoored.
This is my concern with things like the Wordpress auto updater, but it seems the trade off is not having to worry about manual patch management. Security vs convenience as always.
How I've been running multiple wordpress installs for years:
user: $sitename
- the 'owner' of the whole hosted dir. rwX
user: $sitename-PHP
- the user that php-fastcgi or whatever runs as, r-X permission on the dir, and write permission on the content uploads directory, but CANNOT write to any plugin install dirs, or upgrade php files.
user: nginx
- can read all files except the wp-config.php file, which is limited to only the $sitename group reading it.
then use wp-cli to do automatic upgrades every few hours, and a localhost-only ftp server for wordpress to do plugin installs with. When you try to install a plugin, it asks for a ftp username, host as password. You put in the $sitename user, '127.0.0.1' and $sitename password, and you're set. Those login details are never saved anywhere, so the admin has to put them in each time (or their browser stores them).
Of course. I actually regard this as a fairly major issue with the Linux permissions model. Far too many people do as the GP and accidentally set all the files to executable. Cleaning up after someone has done this on a nested set of subdirectories is quite tedious.
NB if anyone has ever run:
chmod -R u+x . or equivalent
and you run
chmod -R u=rwX the files will stay executable...
You can always use find to set all files to +x and directories to -x but then what if some of files needed to be executable?
