Прошу прощения за избитый вопрос. Какие права нужно выставлять конкретно на папки  cache\skin_cache\cacheid_0? Я знаю, что на cache выставляется 777, а на сами подпапки не знаю что лучше, 755 или 777. Тоже самое интересует и относительно других папок. Ставим к примеру 755 на папку ips_kernel, а на подпапки внутри этой папки какие права выставлять?

Знаете, в домах, на щитках обычно висит такая надпись "Не лезь - убьет(на#$й к е#$!м)", но некоторые все равно туда тыкают палочкой... своей... маленькой. Но не в этом суть. Если не знаете, чего же тогда пытаетесь ковырять? Автоматически при установки IPS права выставляет сам. Если Вам требуется что-то модифицировать коль Вам не нравится, то прошу

Показать контент

Presuming that a 'web application' runs on a server (like apache, nginx, etc) and is written in some dynamic scripting language (like PHP, Ruby, etc), you have a misunderstanding in who the 'user' is.

The user is not the person who is logged into your application - that, and their role in the application (admin, etc) is completely irrelevant to the scenario. The user is the linux system user that the process runs under. The code of your website is run as only one user - it may be the user of your webserver (which isn't really a good thing), or it may be a user specific to your site (which is much better).

On linux, users belong to groups - we can add a user to another group and assign privileges to that group.

A good setup will have your server run as one user (let's call this user 'webserver') and your dynamic scripting language run (e.g. via FastCGI) as its own user (one user per site - let's call our first user 'site1').

To serve your files, the webserver needs access to them, and the scripting language needs access to them. That means: 'site1' and 'webserver' need to be able to read your files. Only one of them, however can 'own' the files. The owner is the 'user' (in user, group, other). We also need our scripting language to be able to write to the directory (and read the files it has written). The user 'site1' therefore, needs read and write permissions. Since we want group and other permissions to be as restrictive as possible, our 'owner' will be 'site1', and the corresponding user permissions will be read and write.

Since we cannot specify the permissions for our webserver as another 'user', we will add 'webserver' to the 'site1' group (you could of course, create a different group with both 'site1' and 'webserver' in it. All members of this group will be given the same permissions. The most lax permissions (of the user, group, other set) will be applied to any given user to determine their permissions.

It is worth noting that a good setup should not require files to have execute permissions for a dynamic language. The files are not directly run, but rather are read into an interpreter - only read permissions are needed to run a typical script (one that doesn't write anything).

The 'execute' permission on directories has a different meaning - it permits traversal without being able to read the contents. In order to be able to read a file in a directory, a user must have 'execute' permissions on EVERY directory above it.

For a web application, every file must have read permissions by its owner - otherwise, it is a fairly pointless file. Whether a user or an admin uploads files (via your web application) the 'owner' (i.e. the dynamic language) needs write permissions. An efficient setup will try to serve static files directly via the web server, as dynamic languages tend to be slow at reading in large files and echoing out the contents. The web server therefore needs read access to your static files.

Therefore, the minimal file permissions may be:

• A file in a directory where user uploaded static files (images/swf/js files) will reside: 640
• A file in a directory where admin uploaded static files (images/swf/js files) will reside: 640
• A file in a directory where libraries used in the application reside: 400 (or 440)
• A file in a directory where executable/browsable server side scripts will reside: 400 (or 440)
• A file in a directory where the already existing files (txt or xml) will be edited by code on server side: 640 or 600
  • (depends on whether the web server will display these, unmodified at times)

While, the minimal directory permissions may be:

• A directory where user uploaded static files (images/swf/js files) will reside: 750
• A directory where admin uploaded static files (images/swf/js files) will reside: 750
• A directory where libraries used in the application reside: 500 (or 550) [should be 510 at least]
• A directory where executable/browsable server side scripts will reside: 500 (or 550) [should be 510 at least]
• A directory where the already existing files (txt or xml) will be edited by code on server side: 750 or 700
  • (depends on whether the web server will serve files from here, unmodified at times)

Once again - your web server must have 'execute' permissions on every directory above the one it needs access to - so even if the web server won't serve files from a given directory, we should grant it execute permissions.

It is fairly common to give the web server read access to most of the files (so change those 500 to 550). Default 'somewhat secure' permissions are commonly 755 for directories and 644 for files - no execute permissions, everyone can read, and only the user can write - you will note that the vast majority of files on a linux system have these permissions.

Keep in mind that the 'other' permissions refer to any system user who is not the owner or in the group (i.e. all remaining system users). Keeping your 'other' permissions restrictive is good, because these users are an unknown - you haven't explicitly given them permission. The other permissions are often the easiest to take advantage of on a compromised system (e.g. one of the reasons why /tmp is a common target).

In the context of the above, I don't think your last two questions are that relevant. Set your directory permissions to 550 (and file permissions to 440), and then grant the user write permissions for whatever directories your application will be writing to (i.e. directory: 750; file: 640).

(You will obviously need write permissions to upload the files - but if you wish, you can remove those afterwards - arguably though, if someone is writing to a directory which only the owner can write to - your account has been compromised - which is one of the reasons for keeping restrictive permissions).

Достаточно интересно рассказано и объяснено. 

SoNWarrioR, суть в том, что сайт переливался из другого хоста. Вот поэтому и интересует такой момент как правильно их выставить именно на подкаталоги.