There isn’t a straightforward answer because so much depends on your hosting environment. Start with your hosting provider’s documentation and support, or with your system administrator, and with the following instructions:
How to set your permissions
In general, you want your permissions set such that your webserver can read and write (recursively) to config.inc.php's files_dir, and to ./cache/, and ./public/. Optionally, for added features and reduced security, you can enable write to config.inc.php, to ./plugins/ and perhaps to the locale .xml files. Your webserver should have read-only access to all other files and directories distributed in the package.
How does Linux do this?
In Linux, permissions are based both on a numeric access control mode, and on file ownership. Understanding this permissions scheme is a prerequisite.
For example, ownership of apache:www with permissions of 750 (rwxr-x---) means that the apache user can read, write and execute; anyone with the www group can read or execute; and the file is protected against access by anyone else. Note that “execute” means two entirely different things for directories than for files!
An Example (for dedicated hosting):
Generally, the ownership of cache, public, and other web-writable directories should be your web user and the web-user’s primary group, for example apache:www-data. Permissions should probably be 750.
The ownership of the other non-web-writable directories should be your user, with either the web user’s group, or with public execute permissions. For example:
myuser:www-data with 750
or
myuser:ourgroup with 755.
Web-writable files would be the same, but without the execute permission:
apache:www-data with 640
Non-web-writable files would be perhaps:
myuser:www-data with 640
or
myuser:ourgroup with 644
But What About Shared Hosts?
With some shared hosts (for example, if your only access is via CPanel or a similar web-based admin tool), you may not have the ability to change the file ownership, and your webserver is effectively running as your user. In that case, you may still have the ability to protect your files by making them non-writable by your own user (even though this sounds counter-intuitive). In a shared host, you will almost certainly want to deny world permissions to your files, but look to the documentation and support for your host in particular.