suphp questions

[HostSafely]

Hello to all,

Okay I know the basics of cpanel servers however this has always been beyond me.

I have 2 servers and am looking to build suphp and suexec into the php configuration.

Each time I build apache 2.0 php 5.2.5 and select the correct stuff, then go into whm and configure suexec & php and select:

PHP5 Handler: suphp
PHP4 Handler: none
Suexec: on

However after I do all this and restart httpd alot of scripts come back with a 500 error, and it seems not to be working correctly.

I have been trying for months to get this working but cannot figure it out for the life of me.

Any help would be appreciated.


Thanks,

Derl

 

[merlinpa1969]

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

 

[verdon]

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.

 

[HostSafely]

Dang

Tried that and made sure all scripts have the correct permissions and groups & owners.

Trying to figure it out as on this new server I've been trying it, as I have another server with customers I would like to employ it on but wanna make sure it works on this other server as it is exactly the same and only has 2 sites on it.

However I cannot get it working correctly, it still gives 500 - internal server errors.


Any help would be appreciated.


Thanks

 

[LiNUxG0d]

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!

 

[norelidd]

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?

 

[LiNUxG0d]

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,

 

[norelidd]

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?

 

[cPanelDavidG]

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.

 

[LiNUxG0d]

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?

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$.

 

[colorcloud]

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

 

[yapluka]

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

Run this command in ssh :

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

 

[brianoz]

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.