Switching to suPHP

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

Code:

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

- Change all permissions for files from 666 to 644

Code:

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:

Code:

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:

Code:

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:

Code:

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.

 

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.

 

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.

 

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

 

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

 

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

 

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:

Code:

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.

 

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:

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

 

Hello Miraenda and cpanelkenneth

Thank you very much.

Konrath

 

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

 

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

 

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)

 

Thanks Michael, now it all makes sense!

 

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?