Prevent apache ownership of installed modules

[pspahn]

Running in a vhosts environment, whenever a new module is installed, it is automatically owned by apache:apache, whereas everything else is owned by user:user.

 

How can I force these installed files to be owned by the user instead? It's a pain to constant have to submit tasks to my IT guys to have them change ownership of these files.

[PrestaHeroes USA]

if you are installing them from the back office, then they should have user.

 

are you ftping the module and not using the admin module install?

[pspahn]

I am using the backend installation method, not using FTP.

[PrestaHeroes USA]

I've sold some modules to folks where their hosts do not run as user...so if the module needed to copy a file outside of the folder...it would not work....

 

I wanted to tell them to move to another host...but I bit my tongue...but now I can say it freely...MOVE!

[pspahn]

So, what you are saying (without actually saying it) is that PrestaShop is doing this with its code, and it's not necessarily a server configuration issue?

 

I say this because other files that are uploaded to the server through the backend are correctly set to the site's group:user (ie. NOT apache). Product images are one example.

 

So at some point, when a module file is installed, it is explicitly setting these files/directories to apache:apache.

 

You may say "You should move to another host", however, this is not the issue. We are the host. The servers are upstairs. Most of our configurations are optimized for Magento, and we have run into a few strange issues with Prestashop sites, this being one of them.

 

I'm taking a quick glance at the FileUploader.php class, and it appears to simply be using nothing but generic PHP functions. I imagine the problem lies in here somewhere, though I don't have much experience with file I/O in PHP, so I will have to look at it further.

[PrestaHeroes USA]

no, it's not prestashop...it's the apache server configuration as set up by your hosting company..typically when one say creates new folder it give's that folder user permission. This is not the case of your server...and a couple of my customers...for example if my module needed to modify a file outside of it's folder....it did not have permission even though it was running with user permission and the file was 'writeable' by user, ..drove me batty...I've only seen this on a couple customer servers...

 

when you ftp an image, it's going into an existing folder

 

fyi: I'm no expert..but you have the same symptoms as a few customers that had this sort of behavior.

Edited December 10, 2012 by elpatron (see edit history)

[pspahn]

when you ftp an image, it's going into an existing folder

 

This is not correct. See the Image.php class, specifically the createImgFolder() method.

[PrestaHeroes USA]

This is not correct. See the Image.php class, specifically the createImgFolder() method.

 

in your example I am correct as this sets permission not the owner...anyway...you are one of the few that has this problem...and I used the examples from real life work with customers...not much else I can help with...good luck

[pspahn]

Thanks for the attempt. I just find it very curious that this is how it works. It is a lot more common to have apache run as user than it is to run as apache. I know that Prestashop is fairly mature with 1.5.x, but I regularly run across bugs that I end up fixing myself (mostly minor, like backend settings not doing what they are intended for).

 

I think part of the problem is that Prestashop is based on Smarty, and Smarty is only designed as a templating engine with the intent that a developer will be using their own framework to abstract out many of their day-to-day functions. But in Prestashop's case, there isn't really a framework to speak of, simply some classes and controllers delegating what smarty stuff to assign.

 

But this isn't a post intended to point fingers at the Prestashop team. After a few more iterations I am sure the platform will improve (at least from a developer's point of view).

[pspahn]

Ha, we ended up adding a cron job to change these resources' ownership automatically. Total hack, but it's one less headache while we search for a proper fix.