suphp questions

you need to try running these to lines in your command prompt

find /home*/*/public_html -type d -perm 0777 -exec chmod 755 {} \;
find /home*/*/public_html -type f -perm 0666 -exec chmod 64 {} \;


suphp will not run if php files or folders are set to let users and other write to files

 

That should be chmod 644 and not 64

Also important is the file ownerships and you may need to run
chown -R user:user /home/user/public_html/* ;

for each account if they are not correct. EG. if there are a lot of files owned by nobody from previous setups.

 

Hey there HostSafely,

These are the considerations when you're migrating to suPHP:

- Files max perm has to be 755; (check for 777, 775, 757)
- File ownership has to be user:user; (check for user and group 99, or 'nobody')
- .htaccess files CANNOT have php_flags in them, they need to be ported to php.ini files;
- .htaccess ForceType's and AddHandlers differ from non-suPHP as well.

These are the only considerations I can think of, that I've put in to place anyway, that make my suPHP builds clean and working, non-500 errors.

Give 'er a go!

 

Why is it good to use suPHP/seExec? Is it because you don't trust your users to upload malicious scripts, or you don't trust hackers to not exploit scripts?

I have a VPS on which I am the sole user with many accounts. If I trust the scripts I am uploading, would I benefit from using suPHP/suExec?

 

There are many advantages. The advantages actually outweigh the disadvantages.

- Untrustworthy scripts will run as the user and not as the web-user (nobody/99);
- Mail script exploits not running as nobody/99.

It's more, "If a hacker hacks you, he will not have access to all user directories, anonymously."

Basically, since the public_html/ folders are user:nobody, well, that means "nobody" can read/execute in the folders... so someone who exploits via XSS (Cross Site Scripting) could potentially find folders that are owned nobody:nobody or that are 777 or 757 or 775 or some combination of permissions. Then they can upload scripts, exploit, etc.

Worst case? Weak kernel, upload script, execute via the web, elevated privilege, owned box. It happens really quickly. The stupid thing? Mostly script kiddies do it, but, it happens quite a bit. I had to clean a box that had 3 rootkits on it just last week, very bad.

Regards,

 

Thanks for that explanation. It's a matter of exploitable scripts and bad surfers/hackers, not so much malicious users that have accounts on the server already, then.

I'll probably bother my host about this later on in the week, when I can babysit it and make sure that all the accounts are working properly.

From my understanding, all scripts and such need to be 644 instead of the more common 755. What about files/directories that need to be edited by other scripts (such as a cache/tmp directory being needed by Wordpress). The instructions usually call for chmodding them to 777, would I still do that or is it recommended/required to use a less "open" chmod?

 

The 777 is required because usually it's user nobody writing those files. In a SuExec/SuPHP environment, user nobody isn't being used to run or do anything, so you can remove global write privileges and everything will still work just fine. Heck, I have my wp-config.php set to 600 and everything works dandy, even configuration changes saved to that file via the WordPress admin interface and has done so from 2.2 (when I installed it on one of my own websites) through 2.5 (the current version) without a hitch.

 

Correct.

Usually, it's a question of the script vendor. If he was smart, he would know that SuPHP/PHPSuExec mechanisms exist, and the only reason he would ask, is to be sure the directories are writeable.

There really isn't a bypass option.

If he explicitly checks for REQUIRED permission 777 on a script, then chances are it won't work, then again... that would be a bad way of doing things. Checking if you can write to the folder/file is much more efficient than letting anyone write to it.

Just my 0.02$.

 

anyone have idea to automatic doing chown -R user:user /home/user/public_html/* with all user in /hom?

 

Run this command in ssh :

Code:

cd /var/cpanel/users/;for user in *;do chown -R "$user"."$user" /home/"$user"/www/*;done

 

Another tip that nobody's mentioned so far: check out the suphp log to see what exactly is triggering the failure, it will usually list the file and the reason for failure. If it's not in the suphp log look in the suexec log. Both are in /usr/local/apache/logs/ .

Something that may help is that when you are searching for write with find, use a permission of -2 and -20 which will search for files with the write bit set, regardless of the rest of their permissions.