Just to be sure - what is the correct permissions for the different directories and files
I have set the following directories (including subdirectories) to 775
config.php is set to 755 - is this wrong?
config_override.php is set to 775 is this wrong?
What permissions should the files in Modules (and subdirectories) have
Permissions don’t mean anything without “ownerships”. So different values could work in different ways depending on who owns the files and directories.
The installation guide in the Documentation includes information about this (and it looks similar to what you have). Just make sure you also get the ownerships right, and for this you need to know the user name your web server is using.
I’m somehow new to Linux - so my questions might sound “strange” (wants to try SuiteCRM for a small association)
It is installed on a VPS running Plesk Onyx (CentOS Linux 7.4). Looking in the file manager it says User: xx (system user of the account) and Group: psacln ‪(psacln and psaserv are actually linux groups created by Plesk and which are used for various services and files. For example parent-level directories that should not be shared between sites uses the psaserv group, and files inside of your site will use the psacln group.)
I want to set the right permissions for files and folders - but also to be sure that I do not provide more rights than nessecary.
Maybe this will work (from your SuiteCRM root directory):
sudo chown -R psacln:psacln .
sudo chmod -R 755 .
sudo chmod -R 775 cache custom modules themes data upload
sudo chmod -R 775 config_override.php 2>/dev/null
as I can run these commands, I still don’t understand it, I use server in cpanel.
I find the suite documentation too short on this topic. Is there a way to set this correctly without root access ? Infomaniak does not allow root access but allows to change permissions through FTP: is that enough to have a stable install ?
I don’t recommend using any hosting that doesn’t allow SSH access with SuiteCRM. It is very useful to have console access, to check logs and for other administration operations. Nowadays you can get very nice (and cheap) hostings that include this. The SSH console is not “root access”, it is normally quite limited in these hostings, but still, very useful.
You can set ownerships and permissions through FTP, but you need to have a way to order it to be done recursively (to an entire directory and its subdirectories). Otherwise you need to do everything manually, folder by folder, and it just takes too long.
There is also a script that does this for you, from one of the users in these Forums
I may be wrong but I know how to modify permission through FTP or SSH but I do not know how to modify ownership without root access ?
Your FTP client maybe can also change ownerships, I think some can do it, at least on some servers that allow it.
Using an SSH console, I think it varies from hosting to hosting. They will surely not let you do just any chown, but they might let you do a chown for a subset of allowed users (like your own, and the one your web server uses, if it’s different).
I’ve seen some hostings just enforce the correct chown and so this becomes irrelevant, it’s already the way it should be. But you can probably check this by seeing the current ownership, and check if it is the same user as the one your web server is running under.
Gracias me sirviĂł este archivo.
Is that 775 on all folders including sub folders and 755 on all files in these folders?
(cache custom modules themes data upload)
It isn’t very clearly specified in the installation documentation:
Thanks…
Sorry, what is not clear?
sudo chown -R www-data:www-data .
sudo chmod -R 755 .
sudo chmod -R 775 cache custom modules themes data upload
sudo chmod 775 config_override.php 2>/dev/null
This starts by putting everything at 755, then increases permissions to 775 for those directories (cache custom modules themes data upload).
If you set the ownership to the exact same user that your web server is running under (as you should), 755 will act exactly the same as 775, since only the first 7 will have any effect (the owner permissions).
Right thanks.
Just don’t understand why the application needs so high privileges on files. Why 755 and not just standard 644 from a security perspective. You can never be too careful…
What is “standard” depends on what kind of app it is. If it’s PHP to be run from CLI it needs both the readand execute bits, at least.
Then the real issue comes with the write permission, which is the most security-critical. The reason for SuiteCRM (and other similar apps) need this set more extensively is because they are apps that write themselves. You change things in Studio and it produces new PHP code.
If you set the ownerships right, and use that username only for the web server and nothing else, you will be safe. For hardening I just remove the “world” permissions (use 770 and 750, drop the third digit to zero everywhere).
Thank you so much for your reply and explanation. 
Kind regards