Apache user and group

A number of users of my websites have been reporting issues concerning not being able to create accounts and upload files. I noted that when I set the permissions of certain upload and caching directories to 777 the profile accounts could be created and they could upload files. Obviously 777 is not ideal. On closer inspection the files and directories that get created once I have set the parent folder to 777 are have a group and user of "nobody". Up until a few weeks ago the folders and files that were created had a user and group of the webhosting users account name e.g. myacct is a webhosting account and all the files and directories that are created should have a user of "myacct" and a group of "myacct" but instead they now have a user of "nobody" and a group of "nobody". I can see why the issues are occuring. My question is what do I need to amend on the webserver to revert it back to the old user and group. I have made no amendments myself and can only assume someone has been fiddling either over at the data centre or the server has been compromised.

Cheers

Paul

I got impatient and googled it. You need suphp installed.

http://www.cpanel.net/documentation/easyapache/ea3php_php_requests.html

All working again. Now I just need to find out how it happened.

Still it gave me a chance to try out Boonex's new forums. Pretty smooth compared to the old ones.

Certain folders need to be writable for the script to be able to upload photos to it, ect. And 777 is the normal mode assigned to such folders.

As for the nobody. That would be normal for any file that was created by the script. It takes ownership of the apache webserver. Thus all uploaded photos would be owned by the webserver. If those were to be changed to the owner of your hosting account, then members would not be able to delete any photos. So nobody as owner is correct depending on what files had that ownership.

But yea, suphp does make the permission and ownership thing easier.

Yeah I understand Deano. The major issue here was that for some reason it was switched over from suphp to dco. So the file ownerships were in a mess. Hence the issues. If it were all "nobody" or all user account ownership then there would have been no problems. However it was attempting to be somewhere inbetween. Yes there is not too much wrong with dco and the nobody account, but as I understand it now, the suphp configuration is much "safer" because it stomps on the ability to abuse the "nobody" owership and potentially run on someone elses account with the user "nobody". I am no expert but it sort of makes sense to me :o) Ho hum