On 28/03/13 11:10, Roger wrote:
Set permissions on /sites/default/settings.php to chmod 777
I am pretty sure you copied that advice, I've seen it before.
It's actually wrong.
Each of those sevens is one octal digit (rang0 0-7).
Each refers to permissions for a class of "user."
The first digit is the owner's permissions -typically whoever created the file or directory, but that can be changed.
The second digit is the group permissions. If the group is "staff" then these bits refer to everyone in the staff group. The owning group can be changed too.
The third digit is "everyone else."
The first bit of each is the write permission. If 1, that class can write the file. This is the only permission that really matters so far as writing is concerned.
The second bit gives the class read access. One might have write access but not read.
The third bit marks the file executable. Windows does it with suffixes such as ".exe" whereas POSIX systems (Macs, Unix and Linux) use this bit. For directories, execute permission doesn't make sense to it grants the class of users the ability to search the directory.
One always specifies the three octal digits, so 056 and not 56.
Users are distinguished by UID, same as drupal. UID=0 is typically called root and can do anything - those permissions don't apply.
Typically, Apache on Linux runs as user=apache or www or similar and as group=apache or www or similar.
I don't recommand your webserver owns anything it doesn't need to write to - the files directory and its contents. If your user account is fred:jones, fred:jones owning those files is fine. Root is good too.
So when your webserver needs to write to settings.php then 466 is fine (if the webserver or its group doesn't own the file). fred:www might be good ownership, permissions might be 460 for update, 440 otherwise.
The world is a whole lot more complicated on linux with selinux enabled - think CentOS and Fedora and clones, respins etc. A common trap is for someone to create a file in one location, maybe their own home directory, and then move it to another. They will often need to change ownership of the file, but that's not all. selinux has its own security information on it too, and moving stuff around doesn't change its ownership or its selinux context. If you're not awake to selinux, things can look all good but still not work because selinux is denying access.
selinux can block access to TCP/UDP ports too, so if you want to send email from your drupal site you will have to enable that. And likely access to your database too.
If it's a pain to administrators, imagine how painful it might be to the ungodly:-)
If you have selinux, use it.