Secure chmod privileges?

Question

The standard chmod privileges are "644" for files and "755" for directories, aren't they?

In most cases, PHP doesn't need to write to files or directories. So couldn't I take the write privileges from all groups?

I could assign "444" to all files and "555" to all directories.

Wouldn't that be more secure?

Thanks in advance!

Note: chmod() is on my PHP's disable_functions list.

Answer 1

It's not more secure since PHP can always do chmod 777 even on 000-chmoded files (if they are owned by PHP). However, it's safer since you cannot write this file without chmoding them before.

Answer 2

chmod() is on my PHP's disable_functions list.
Wouldn't that be more secure?

Using disable_functions is possible to disable specific functions.
If chmod() appears in the disable_functions directive, it's not safer to use; it is simply disabled, and PHP code that is using chmod() will raise a warning.

The directive disable_functions should not be confused with the Safe Mode directives. disable_functions is active even when the directive safe_mode is set to 0; when safe_mode is enabled, some functions are disabled, or are restricted.

To notice that Safe Mode is considered deprecated, in PHP 5.3; this means that the directive is still accepted in PHP 5.3, but it could be not used anymore at any time.

Answer 3

The default permissions for newly created files and directories are set by the umask environment variable. The file's owner and root can change the permissions.

If you don't need to use chmod in your app, then leave it in your disable list. They way you should look at security is: Many people smarter than me have now make chmod one of the more secure parts of my application. Therefore, I will spend my available time making the other parts secure.

Making your application read-only, on the server, is ok to do if you automate it. When you make changes to your application code, it's going to make things very difficult for you though. At some point, you will go back and forth, making some code changes and testing them on the server... and then forgot to reset your file/directory permissions back to read only.

If you only have 1 user account on your production machine, I would just stick with the default permissions- things are probably managed for you. Or you can remove group and "other" permissions, as described below.

A typical production setup, would be to have an application group that you belong to. You also want a separate user for running your php application. Keep full permissions for the owner and group, and remove all permissions from "other". This way:

• Developers keep their individual logins - you can track who did what when.
• You and other developers can copy new code to the server.
• The application can run the code.
• The application can not access anything outside the code.
• No other users else can see your code.

I'm guessing it's someone else's job to manage your production server? They will spend time to make sure no one can login and poke around. While you do need to make sure no one can run operating system commands, I think the best place to start is to learn about xss. The default php server settings should be ok. The least secure part of the application, is the part only you have seen. If someone is going to access a system call, it most likely to be through a form. Even if you eliminate system calls, the forms are still susceptible to storing javascript. Unless you are storing credit cards in your application, the more likely target would be the password/session in your user's browser.

Answer 4

Sorry for my english.

I am thinking in three possible reasons.

1. Check safe_mod flag in your php.ini, if safe_mod is ON you maybe get some problems with that function.
2. If you have plesk, you get problems if you create folders or files with another user which has not been created with plesk.
3. Likely you are missing a php library.