Is there a way to specify who default owner of runtime generated php files is?

[southwestcrm]

All versions on an ISP hosted shared server...

Mainly issues with files like
%%46^466^46613B54%%EditView.tpl.php in directory /cache/smarty/templates_c etc...

these sorts of files seem to get generated when editing custom fields and layouts etc... there are many different situations when these files are generated in a range of folders.

My problem is the owner of these files is set to "nobody" and not the root user which is my account. So when i try and edit them I hit fatal errors shown in the error.log

So my question is, have I misconfigured the site or is there a setting somewhere which tells Sugar which 'user' to be the Owner when creating files on the server

[dpatech]

For linux-based systems these files will be owned by the user used to run Apache. If Apache is running as "nobody" then that is why your files are owned by "nobody". You will have to discuss this with your hosting company, but it isn't configured properly if that is the case.

[southwestcrm]

For linux-based systems these files will be owned by the user used to run Apache. If Apache is running as "nobody" then that is why your files are owned by "nobody". You will have to discuss this with your hosting company, but it isn't configured properly if that is the case.

Thanks DPA for your valued input. As a result I have been quizzing my ISP and they say: "Our server is configured correctly. CRM scripts creates by default nobody files. This is OK"

Is this right or is it time to seek another ISP?

[HolmesA]

ISP is right as this is one of the proper ways to setup apache. Sometimes apache web server is configured to use "apache" as a username instead of "nobody". It is very rare when you would like to run apache as a "root" user. This will create a potential security issue.

The easiest way to resolve your issue is to setup proper permissions to the whole folder that need files to be created. For example
chown -R 766 ./cache
will allow read/write (but not execute) to the whole cache folder ignoring the owner.

Let me know if this helps.

[southwestcrm]

HolmesA, you're a star. As it turned out the folder where the ZIP file was being uploaded to had 0 permissions set. As soon as I gave this folder 777, the ZIP file, whilst still onwed by 'nobody' could be opened on the server and the content extracted. This enabled the module loader to continue (where before, it failed). So thanks for your help. Much appreciated.

[HolmesA]

Excellent. 777 may be to much though as it means anyone can run executables from these folders. No need to have execute permissions there due to security reasons. 766 should work.

[southwestcrm]

Excellent. 777 may be to much though as it means anyone can run executables from these folders. No need to have execute permissions there due to security reasons. 766 should work.

I'm led to believe from my ISP that as long as I have low-level permissions set at public_html level it doesnt matter about the permissions underneath.

It is also a massive admin effort to set different permissions on folders and files as I have to do each one manually. whereas in an FTP pprogram I can recursively update all files in one go.

If you have any comments/views on the above they would be welcomed

[HolmesA]

I would agree that 777 for cache folder is not a big deal.

But in any other case, assuming an internet user can upload any executable file through web browser, having 777 allows to find a way how to run this file later.