[SOLVED] Permissions Issues

[Teddy's Dad]

Hello all

 

I am testing Presta 1.4.7.3 and am trying to rever the permissions back from the requirement for setup. I am testing this on a Linux server.

 

The problem I have is that the folders "/img" and "/upload" need permission level of 777 to operate. Anything lower and I cannot upload product images in the BO or let a customer upload a file (in product customisation) in FO.

 

This is a major security risk, meaning anyone can stick a malware in these 2 well known folders. Am I doing something wrong or is this a serious problem?

 

Any thoughts would be highly appreciated.

 

Regards

 

Nima

Edited May 30, 2012 by nkamkar (see edit history)

[indus]

Hi

On any good hosting provider, the permissions are automatically set to 755 for folders and 644 for files. Prestashop runs fine with these permissions.

 

Just use 777 when testing offline on your localhost. But its true during my testing too i found presta wont work without the 777 permissions on my local machine. Strangely 755 works fine with most hosting providers.

Edited May 18, 2012 by indus (see edit history)

[chootchyface]

This is also an issue for me. Firstly the idea of setting directories to 777 is absolutely out of the question, secondly, I've also had issues with the fo not displaying at all due to the perms required by Prestashop.

I've manually upgraded Prestashop to 1.4.8.2, which I had to do by setting 777's on a number of directories, I've now reset those (for obvious security reasons, discussed both on this and other posts) to 755 and also tried 775 no good though the FO was displaying with 777 perms but not with 775 or 755's.

 

Anyone got an answer to this one?

Edited May 25, 2012 by chootchyface (see edit history)

[chootchyface]

Have an answer to the problem of the FO returning a 503 error with perms set to less than 777. Disenabling caching of smarty now show the site with 755 perms on all directories and 644 for file. much safer although not sure about the consequences, a reply on this from the Prestashop team would be good

[codegrunt]

The issue is that the user the web server is running as needs write permissions to these folders. If your server is running Apache (or whatever web server they are using) with something like suexec for PHP then 755 will be fine as the PHP process will run as the account user. However, if the web server is running as "nobody" or similar unprivileged user then they have to be 777 for PHP to write to them. If that is your situation and you are (for example) running in a shared hosting situation where you cannot trust the environment your only choice is to switch servers.

 

This is not a Prestashop problem, it affects every single web application on the planet that needs to write to files.

 

Cheers

[chootchyface]

Thanks to @codegrunt for the clarification. This makes sense, I guess time to check the installation/availability of suexec or similar.

[Teddy's Dad]

Hello all

 

I have finally been able to fully resolve this issue, based on some research and also some good hints from the likes of codegrunt. The issue is the user who is running the process. Here are my settings and the steps I took:

 

Settings:

1. We host our own servers so we have full control over the OS
   
2. We run a linux server and we use Plesk for the control panel
   
3. We also use Plesk to create the domains on our webserver
   
4. When you create a domain using Plesk
   
   1. 
      
   2. the httpdocs folder's owber is set to the default ftp account for that domain
      
   3. Imagine the domain = www.example.com, ftp user = "ftpexampleuser"
      
   4. then the owner of httpdocs and all the subdirectories are "ftpexampleuser"
      
   5. the group for httpdocs is set to "psaserv" (Plesk Process server) and for all the directories under httpdocs is set to "psacln" (Plesk Process client)
      

[*]Under these settings, folders such as "download", "upload", "img", "cache" and any other folder which the backend admin needs to write to MUST have 777 as permission in order to write.

1. This is because the actual process running the website does not have permission to write to these folders,
   

Solution

1. All I had to was to find out what user is responsible for running the website.
   
2. I am sure there are more elaborate ways of finding this out, but this is what I did (rough and quick)
   
   
3. I set the "img" folder permission to 777 so I can write to it.
   
4. From the backend, I went to catalogue, edited a product and uploaded an image through the Presta admin. I checked the name of the file through the backend (just hover the mouse on the image and it will show you the url)
   

   [*]I checked the properties of this file

   1. when the backend uploads the file, it assigns the user and group of the process running it, as the owner.
      
   2. In my case this was called "www-data"
      

   [*]All I did next is to change the ownership and group of all the writable folders (img, upload, cache, etc...) to this user "www-data" and then with permission level of 755, I could do everything I couldn't do before

   So in summary, the owner and group of these writeable folders must be the same as the user running the web process and using the above method, I found out which user that was and I re-assigned it to the relevant folders.

    

   I hope this helps someone else too.

    

   Regards

    

   Nima

In my case, for example, this was "/img/p/10-139.jpg"
Edited May 30, 2012 by nkamkar (see edit history)

[indus]

I think this can be cleaned up and made a sticky about permissions.

[chootchyface]

Fantastic, thanks to nkamkar and codegrunt for their input, works for me

[codegrunt]

Sorry nkamkar but if I am reading your explanation correctly it sounds like you have a problem.

 

If the web user is a generic unprivileged one (such as "www-data", "nobody", etc.) and not owner of the account (via a suexec CGI mechanism) you should NOT change ownership of the parent directories to the unprivileged user.

 

First, unless the permissions are again set to 777 you will have removed the ability for the owner of the account the pages are hosted under from manipulating those directories (for example, deleting them via sFTP). Second, this defeats the original purpose of tightening security as any PHP script on the server will now have access to these directories (since they all run as the same unprivileged web user). The whole point of the web user is to give the HTTPD daemon process the minimum privileges necessary to do its job.

 

What you want is for PHP to run as the user who owns the account the scripts are located under. cPanel supports this and can run php via a suexec mechanism. A Google search for "php suexec" shows this from the cPanel docs:

 

http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/RebuildPhpconf

 

"suphp" is the option you are interested in if memory serves. You should probably be talking to your webhost for assistance here but in any case, there are some example docs.

 

If you cannot implement a suexec option then you need to go with the standard chmod 777 for directories and chmod 666 for files that the web daemon needs to write to and leave ownership as the local user's account.

 

Cheers

[Teddy's Dad]

Thank you for your comments codegrunt. I will look into this and talk to our tech support and post the results here.

 

At least we are making some progress. Before anyone from anywhere could write to our website, but now it is only the internal server. Since the server is ours and so are all the websites, this is not an issue, but as a metter of principle, I will try and implement this and see how it goes.

 

Many thanks and I will update soon.

 

Nima

[cyremia]

FYI

I had the same issue (i.e. BO was telling me to change the permission to some of the folders (img, upload...) But only CHMOD 777 worked)

 

I installed suPHP on the server and it solved the all thing.

 

Thanks for the recommendation.

[uktech]

Unsure if this will be of any use to anyone BUT I also had problems as Apache had taken ownership of files.

Did a Chown (user and group) to swap all files to the FTP User and Group then configured the server to run as FastCgi, no crazy permissions required at all now and not a single permission error at all.

Am aware of the upload limitations but that is/was easily resolved (Found a guide to double check with in Google for reference)

CentOs + Plesk Dedicated Server

 

Cj