Switching to suPHP

[Hitakashi]

I'm wanting to switch to SuPHP due to
FCGI - uses up all our RAM (We have 768 MB's)
dso - causes random spikes in RAM usage
cgi - Rather not use it
None - Rather not use it

Our host switched us from suphp to FCGI, Which caused it to eat up our RAM, Then they switched us to dso which we are on now, But it causes random spikes in RAM.

We WERE on suphp originally and our ram load was always around 30% -40%, But now it's always in the 50% and randomly goes all the way to 100%

Is there any steps we have to do to switch over to suphp? If so can anyone give me like a short tut, I looked over the web and couldn't find anything to help.

Thanks

 

[Miraenda]

I posted this recently in another thread, so I'll reply with the steps I noted there for switching to suPHP. Of note, only use these steps if going to suPHP (do not process these if you are on DSO).

- Change all permissions for folders from 777 to 755

find /home/*/public_html -type d -exec chmod 755 {} \;

- Change all permissions for files from 666 to 644

find /home/*/public_html -type f -exec chmod 644 {} \;

- Fix ownership to public_html contents to user:user (rather than user:nobody), but keep top level of public_html as user:nobody

See this location for why to be careful about using a recursive chown to fix these ownership issues. Use the steps noted at this post as a guide for how to fix such ownership issues.

- Remove any php_value and php_flag entries in .htaccess files as they will produce an Internal Server Error if in an account's .htaccess file. Here are the commands to find all such files:

find /home -type f -name '.htaccess' -exec grep -Hrn 'php_value' '{}' \;
find /home -type f -name '.htaccess' -exec grep -Hrn 'php_flag' '{}' \;

After those php_flag and php_value lines have been removed from any .htaccess, then any accounts needing the values set in their own php.ini file could be done using:

cp /usr/local/lib/php.ini /home/username/public_html/php.ini
chown username:username /home/username/public_html/php.ini

Then edit the php.ini file to change to the new values, and point the .htaccess on that account to use that php.ini file:

suPHP_ConfigPath /home/username/public_html/

In these examples, replace username with the actual cPanel username.

Also, under FCGI for the RAM usage, you could have used FcgidMaxRequestInMem to limit those PHP processes from using so much memory:

http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestinmem

There are several other limiters there. For DSO and suPHP, you can use RLimitMEM to limit memory:

http://httpd.apache.org/docs/2.2/mod/core.html#rlimitmem

If your RAM usage is this high, either limiting memory usage or tracking down the account(s) causing it would be in order.

 

[philipalex]

you can do it from the WHM

Main >> Service Configuration >> Apache Configuration >> PHP and SuExec Configuration

Also please make sue that for using the suphp the files permission must be 644 and the folder permission must be 755.

 

[cPanelKenneth]

for i in `ls /var/cpanel/users/`; do chown -R $i:$i /home/$i/public_html ; done

A word of caution here. The above command can allow a user to take control of files on the same file system. See this article for more details: SysAdmin Tip: recursive chown can open your system for exploit « Power Prose

 

[Miraenda]

Thank you for the link, Kenneth. I wasn't actually aware that hard links on the same partition owned by another user could result in that behavior. If you'd prefer that I remove that line in my post above (and in another thread where I also provided that command), I could do that.

 

[cPanelKenneth]

Thank you for the link, Kenneth. I wasn't actually aware that hard links on the same partition owned by another user could result in that behavior. If you'd prefer that I remove that line in my post above (and in another thread where I also provided that command), I could do that.

That's probably the safest.

The problem is the recursive chown because one does not know what is being changed. To perform the ownership change one has to follow a process like:

1. Lock the user out of the system
2. Lock the user out of the directory tree to be changed [a]
3. Examine each file to determine if it is a hard link to data the user shouldn't have access to
4. Only chown files and directories verified safe by step 3
5. Restore user access to the directory tree
6. Restore user access to the system

This way you only change ownership on files you've proved are safe. By locking the user out of the system and directory under examination you also prevent race conditions between performing the check and changing ownership.

Notes:
a. Rather than starting at the top of the tree, the procedure should really start at the leaf nodes ( the deepest points of the directory tree ). Complete work on the deepest nodes and work your way to the top of the tree ( the top-most level would be /home/user )

b. Since the hard link files will still have ownership of the original file the full range of file to examine can be reduced to the following set:

• root:root
• root
• other_user:root
• other_user:nobody
• nobody:nobody

The list is representative, not exhaustive. Granted for converting from PHP DSO, the list of nobody owned files could be extensive . Root owned files, unless you know that you placed them there, should send up huge warning flags.

 

[Valuehosted]

Excellent tutorial...

Quick ? - will the command "find /home/*/public_html -type d -exec chmod 755 {} \;" change the directories to 755 or will it display a list of directories that have other permissions set?

Thanks,
--Tone

 

[Miraenda]

The command will change those directories to 755 rather than print them out.

 

[Valuehosted]

Thank you Miraenda - I sent you a private message, if you wouldn't mind getting back to me.

I recognize the issue with recursive chown but is there anyway you could post or mail me the code to run it anyway? (all my "clients" are me, and I tend to trust myself! :p).

Whatabout file permissions that are set to 777 and needs to be downgraded to 664 will the above line convert those too?

--Tone

 

[Miraenda]

The command for 755 will change directories to 755 (not files), while the one for 644 will change files to 644. Under suPHP, directories should be 755 and files 644, so the commands will work properly to change those to the right ones (they don't look at the current file permissions but simply whether it is a directory or file and change appropriately).

To read it, basically this command:

find /home/*/public_html -type d -exec chmod 755 {} \;

Means to find any folders recursively in /home/*/public_html that are -type d or a directory, then to execute a chmod 755 on those directories.

The other command has -type f, which is a file and will change the files to 644.

 

[Valuehosted]

Thank you Miraenda,

I really appreciate your help; and honestly, I cannot believe it was that "easy".

I have been dreading this move for a very long time and I have known that I indeed needed to do it but I thought it would be way too hard and with your help it was a breeze.

I would suggest adding the last step as per your email:

After you change the permissions (chmod and chown commands), you can then go to WHM > Apache Configuration > PHP and SuEXEC Configuration area and switch the handler to suPHP if it is listed there. If it isn't listed there, you'd need to run EasyApache in WHM and select suPHP during the Apache portion (it will be an option you can select).

I would actually encourage switching to suPHP first, then running the chmod and chown commands after you have. That way you'll already have it on suPHP and know that option is set before making the changes.

It was awesome to change a site's configuration (Joomla) without having a file permission of 777 on the configuration.php file!

Again, thank you so much for your help!

Kind Regards,
Tony

 

[konrath]

Hello Miraenda and cpanelkenneth

Thank you very much.

Konrath

 

[sukil]

Hi Miraenda and cpanelkenneth,

I find after enabling suExec, a person can access any system file including /etc/passwd. I understand one has to copy the php.ini file to each user's folder and to put in the open basedir protection code in it. However, it means users can change php.ini and delete the file or I need to restrict that activity and loose out on one advantage of suExec of giving each user their own php.ini.

Next, I have 200 different customers in my server and I find it difficult to do that to all of them. Next, for every new customer it is no more just an account creation but to copy the php.ini file and secure it against editing. That is time and resource consuming.

So, ultimately is suExec with all its advantages at all advantageous considering the hazard of maintaining security?

Please comment as I am really utterly confused and although finding suExec appropriate for my users but cant implement due to the hazard of maintaining security as then I am responsible for security and need to dedicate valuable time to ensure all steps are taken for each client (existing and new).

Thank you,

S

 

[cPanelTristan]

I've previously posted a guide on how to lock down php.ini and still allow some php.ini changes for users regardless:

http://forums.cpanel.net/f185/methods-increase-security-suphp-restricting-who-can-use-php-ini-files-167186.html

This would prevent users from changing all settings depending on which method has been chosen.

One point that I'm unclear about--if you wish to set open basedir restriction in the global php.ini, it should be impacting all the accounts unless you have individual php.ini files overriding it for some reason.

In the long run, though, you would be responsible for security on your machine. Security isn't a one time incident but a constant vigil for any server administrator.

 

[openmind]

That's probably the safest.

The problem is the recursive chown because one does not know what is being changed. To perform the ownership change one has to follow a process like:

1. Lock the user out of the system
2. Lock the user out of the directory tree to be changed [a]
3. Examine each file to determine if it is a hard link to data the user shouldn't have access to
4. Only chown files and directories verified safe by step 3
5. Restore user access to the directory tree
6. Restore user access to the system

This way you only change ownership on files you've proved are safe. By locking the user out of the system and directory under examination you also prevent race conditions between performing the check and changing ownership.

Notes:
a. Rather than starting at the top of the tree, the procedure should really start at the leaf nodes ( the deepest points of the directory tree ). Complete work on the deepest nodes and work your way to the top of the tree ( the top-most level would be /home/user )

b. Since the hard link files will still have ownership of the original file the full range of file to examine can be reduced to the following set:

• root:root
• root
• other_user:root
• other_user:nobody
• nobody:nobody

The list is representative, not exhaustive. Granted for converting from PHP DSO, the list of nobody owned files could be extensive . Root owned files, unless you know that you placed them there, should send up huge warning flags.

I'm planning a migration to suPHP and the changing of ownership of files on a shared server of over 200 accounts is the one part causing me a headache. I don't allow shell access on a permanent basis to the server but I'm still concerned about doing a recursive shown.

I don't suppose the above steps are scripted up anywhere are they as they do appear to be the safest method...

 

[cPanelTristan]

The steps aren't scripted to my knowledge, but the best way (rather than to do a recursive chown at all) would be to get a listing of all files owned by group nobody. Those are the only files that would even need to be changed. When you get the list of files, check that the list of group nobody files aren't hardlinks.

 

[nivekau]

Thanks to all who have contributed to this helpful thread.

I am just about to make the change from DSO to suPHP because we want to run the CloudLinux PHP Selector which isn't compatible with the DSO handler. There are a couple of questions that are troubling me.

I have some vbulletin forums on my server which create files owned by user:nobody . Now I'm fine with changing the ownership of these files. But what happens after I switch to suPHP? will uploads from the forum still work? will the files simply be owned by the cpanel account user, or will the upload fail because they cannot be created by nobody?

My second questions relates this helpful post by Miraenda. Specifically this "keep top level of public_html as user:nobody" - why do that? (I presume suPHP will allow that)

 

[cPanelMichael]

1. The uploads should work without the need to modify ownership. Note that you should modify ownership to the account username for existing files owned by "nobody" under this vBulletin installation.

2. cPanel with suPHP requires the public_html directory itself is owned by the account username, with group ownership set to "nobody" (e.g. the web server).

Thank you.

 

[nivekau]

Thanks Michael, now it all makes sense!

 

[nivekau]

One more question if you don't mind. What owenership and permissions should be set for a folder which is on the same level as public_html ?

For example, on one account we have a folder /home/vbattachments this contains a tree of folders all containing image files.

It needs to be written to by vBulletin when users upload files. So should the owner:account username group:nobody and 755 for folders and 644 for files?

- - - Updated - - -

sorry I made a mistake in my previous post, the folder in question is located at; /home/account/vbattachments

on several other accounts there is a folder on the same level as public_html to which an external user uploads xml files which are then processed by a script on that account

so /home/account/xmlupload

what ownership and permissions should be set for these folders?