Shared Hosting
Irrespective of advice to the contrary, no files or folders ever need to be set as 777 (world readable, writable and executable). While it may fix the problem you're seeing, it leaves the files in question able to be written by any other user of the server. This then means that if a vulnerability on any service on the server is exploited an attacker gains complete access to the website.Permissions on shared hosting should normally be 755 for directories and 644 for files, with ownership of user:user for both the public_html directory and for everything within this directory. Please get in touch if you need permissions reset.
Files that store database credentials, such as Magento's app/etc/local.xml and Wordpress' wp-config.php, should have permissions of 600, to prevent other users on the same server being able to read the username and password of your database, giving them full access to your database.
VPS
On cPanel Apache runs as 'nobody', while user accounts use the ownership / permissions of that specific account user. Files and folders normally need to have user:nobody ownership, and 775 / 664 permissions for directories / files.On non-cPanel VPSs, Apache / PHP processes run with the permissions of the 'web' user, so ownership should be web:web, and permissions 775 / 664. The group write is so that additional users can also write to these files if required.
As on shared hosting, database configuration files should have permissions of 600.
As on shared hosting, database configuration files should have permissions of 600.
Restricting individual users
You can add additional users on non-cPanel VPSs, or add additional FTP users from cPanel on WHM VPSs. Please note however that even though a user's SSH / FTP file access may be limited to a specific directory, a determined malicious user would be likely to be able to access files outside of this directory (either reading from SSH, or read/write from within PHP), and as a result could also access all databases on that server. This is because the fastest and simplest way of running PHP is mod_php (more on PHP-FPM elsewhere), where Apache runs as the same user for all virtualhosts.
While there are mechanisms that can help prevent PHP from reading outside of its home directory, these produce such profound performance impacts that their use in production is not practical. You can also run individual users for separate vhosts, however you then need to ensure that permissions are (and always remain) secure, and that there aren't any writable directories - if at any point a developer decides to chmod a directory to 777 then any other user can write to it and then execute arbitrary code as that user.
The real solution is to not allow untrusted developers any level of access to a production web server. Code should be developed, tested and demonstrated on a separate system, and virtually all professional developers have such systems and prefer to work on them, rather than on production. Once the code is tested and you're satisfied as to its quality, the absence of malicious code and so on, it should then be deployed to production by a trusted developer.
The real solution is to not allow untrusted developers any level of access to a production web server. Code should be developed, tested and demonstrated on a separate system, and virtually all professional developers have such systems and prefer to work on them, rather than on production. Once the code is tested and you're satisfied as to its quality, the absence of malicious code and so on, it should then be deployed to production by a trusted developer.
