Apache 'nobody' group prevents MODx Evo user graphic uploads

Various 'nobody' user issues I believe were raised here before but I don't recall a solution. I'd like to describe my problem from the perspective of my web site and try to solicit any relief from those of you who have met the issue head on.

The initial MODx installation was done for us by a developer who FTPed the files as, let's say, user OWNER. Therefore the ownership on the \assets\images folder show as OWNER OWNER.

We have 3 subdirectories inside 'images' where we've uploaded many graphics. PHP created these so the ownership of these 3 directories shows as NOBODY OWNER.

To accommodate this the developer set file permissions of 777 on the images directory and that's the way it was for 2 years ... until our site was hacked recently and spam generators of a p*o*r*n*ographic nature were installed in the 'images' directory. Very embarrassing! Our hosting company monitors spam activity and when they saw what happened they removed the offensive code and set a CHMOD on 'images' to 755.

So, we're now at a point where MODx can upload graphics to the 3 subdirectories of 'images' but will suffer permission-related errors when our users try to upload graphics to the root of 'images'. We're kind of stuck at this point, and the hosting company told us nothing can be done for us.

The only thing I personally can do is have people send me graphics they need placed in 'images'. What I have to do is change 'images' to 777, FTP their images, login to MODx and open the 'images' directory so that PHP can generate thumbnails for the new images, and then reset 'images' to 755. I actually am using 775 and that seems protective enough.

This nightmare must involve many more installations than just me.

Is there a solution, especially one which doesn't require any great concessions from the hosting company?

Thanks very much ... Sam

If you cannot have the directory set to 777 then MODx (or any other scripts run by the webserver) cannot write to the directory. This security issue is why I have made it a point for years to only host on companies that provide some form of "suexec" (Switch User EXECute), where .php scripts are run as the .php file's owner, not as the webserver user.