[support] Moving hosting, site no longer works

[John Summerfield]

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.