HOWTO: PHP 5 CLI to PHP 5 CGI + suPHP

Secure directadmin with php5 CGI+SuPHP

Hi
if i use this option, all new (and current) users have access to other users directory
(its ignore from apache_public_html=1 in directadmin.conf)
how i can work with this script and create account with public_html = 710 with apache group ?
 
paix said:
Ok, fine. This right direction.
But I suggest you locate users php.ini in place unavailable for users. For example:
Code: 
|
        SetEnv PHP_INI_SCAN_DIR /usr/local/directadmin/data/users/|USER|/

otherwise users can be able modify php.ini setting such as open_basedir, disabled_functions, etc...

I've not tested this with suphp, but this schema works fine for me with mod_fastcgi, so it should work with suphp too.

PS. another way is setting chflags\chattr on your users php.ini files, but I think this way is more difficult for maintaince.
Click to expand...

Hi, you can simply use chattr +i for php.ini and release it when you want to...

Regards,
Nservices.
 
circlesquare said:
Correct, you can't use .htaccess files to specify PHP config options using suPHP. The howto explains how to create custom php.ini files for each user. If they want custom PHP config, you can specify it in their php.ini file (/home/user/php.ini)
The reason why you must not give the user's themselves access to change this file is because they can then change the open_basedir restriction.
Click to expand...

Your solution is not safe at all. If PHP_INI_SCAN_DIR is set, PHP will scan the complete directory (not recursively though) for .ini files. You can protect your custom php.ini as much as you want, a user can create ie. hack.ini and override those settings.

We are using a customized version of your bash script. It supports a per user temp directory as well.

Code: 
#!/bin/sh

# create custom temp directory
rm -rf /home/$username/tmp
mkdir -p /home/$username/tmp
chown -R $username:$username /home/$username/tmp
chmod 755 /home/$username/tmp

# create custom php.ini
rm -rf /usr/local/directadmin/data/users/$username/php/
mkdir /usr/local/directadmin/data/users/$username/php/
chown $username:$username /usr/local/directadmin/data/users/$username/php/
touch /usr/local/directadmin/data/users/$username/php/php.ini
echo "open_basedir = /home/$username/:/tmp/:/var/www/html/" >> /usr/local/directadmin/data/users/$username/php/php.ini
echo "upload_tmp_dir = /home/$username/tmp/" >> /usr/local/directadmin/data/users/$username/php/php.ini
echo "session.save_path = /home/$username/tmp/" >> /usr/local/directadmin/data/users/$username/php/php.ini
chown root:root /usr/local/directadmin/data/users/$username/php/php.ini
chattr +i /usr/local/directadmin/data/users/$username/php/

exit 0;

We're using chattr to protect the directory from outside access. This limits maintenance a tiny bit, but increases security. For the removal of a user the following is needed:

Code: 
touch /usr/local/directadmin/scripts/custom/user_destroy_pre.sh 
chmod 755 /usr/local/directadmin/scripts/custom/user_destroy_pre.sh
nano /usr/local/directadmin/scripts/custom/user_destroy_pre.sh

Add the following code:

Code: 
#!/bin/sh
chattr -i /usr/local/directadmin/data/users/$username/php/

exit 0;

Make sure it's accessable:

Code: 
chmod +x /usr/local/directadmin/scripts/custom/user_destroy_pre.sh
chown diradmin:diradmin /usr/local/directadmin/scripts/custom/user_destroy_pre.sh

The httpd templates should be changed accordingly:

Code: 
|*if SUPHP="1"|
        SetEnv PHP_INI_SCAN_DIR /usr/local/directadmin/data/users/|USER|/php/
|*endif|

Open /etc/httpd/conf/httpd.conf and change the following (within the /var/www/html/ directory configuration):

Code: 
   <IfModule mod_suphp.c>
        suPHP_Engine On
        suPHP_UserGroup webapps webapps
   </IfModule>

To:

Code: 
   <IfModule mod_suphp.c>
        suPHP_Engine On
        suPHP_UserGroup webapps webapps
        SetEnv PHP_INI_SCAN_DIR
   </IfModule>

Thanks for the howto though.
 
Last edited:
Interesting discussion.

I look forward to seeing how this progresses. I'll be setting up a test box with the concept tomorrow and trying several scenarios.
 
Joseph, until now we have not seen any issues. While there were a few on accessing phpMyAdmin and squirrelmail at first, they are solved now. The howto has already been changed accordingly. I'll add the steps from the TS tomorrow so it's a full howto.

If you experience any issues using this please let me know.
 
I went through the sets for this how to, converting a PHP5 CLI to PHP5 CGI/suPHP server which was built up but not in production yet. When i create a new user and upload files to the public_html dir, the public_html and all included files are still in the apache group.

Did I miss a line somewhere that needs to update the template for creating a user with user:user for the directories?
 
opussupport said:
I went through the sets for this how to, converting a PHP5 CLI to PHP5 CGI/suPHP server which was built up but not in production yet. When i create a new user and upload files to the public_html dir, the public_html and all included files are still in the apache group.

Did I miss a line somewhere that needs to update the template for creating a user with user:user for the directories?
Click to expand...

Did you do:
Code: 
ls -l /home | grep '^d' | awk '{system("chown -R " $3 ":" $4 " /home/" $9 "/domains")}'
 
Yes, I did that and it worked great for converting existing user directories, but if i create a new user, it's directories are set up as user:apache still.

Would this be any different if i had selected to setup with suphp during the initial install?
 
Does DA set up user directories for newly created users with the proper ownership for suphp to work for you guys by default?

I reinstalled and selected cgi php, but when i create a new user, i still have to go back and fix file ownership. Is there not a setting in DA that should be creating directories with the proper ownership when it is built with cgi/suphp?
 
Is it possible to switchoff suPHP for one domain / user?
I still have problems with a script what doesent work with suPHP
 
So am I the only person that has to manually set correct ownership of files/dirs when using suPHP? Or is that normal?

opussupport said:
Does DA set up user directories for newly created users with the proper ownership for suphp to work for you guys by default?

I reinstalled and selected cgi php, but when i create a new user, i still have to go back and fix file ownership. Is there not a setting in DA that should be creating directories with the proper ownership when it is built with cgi/suphp?
Click to expand...
 
opussupport said:
So am I the only person that has to manually set correct ownership of files/dirs when using suPHP? Or is that normal?
Click to expand...

I've not run into this issue.. new users are created with the correct ownership. A quick and dirty work around if you're still having issues is to automatically do it in /usr/local/directadmin/scripts/custom/user_create_post.sh
Code: 
chown -R $username:$username /home/$username/
 
Hi Circlesquare,

Thank you for the great How To. I also decided to change from cli to cgi because I need some features like mkdir to exclude use of 777 dirs and want keep a clear view of the users who use those scripts. But I have a few suggestions and questions:

More secure
Now lets enable open_basedir per user, and create user's own tmp directories to make the server more secure.
Click to expand...

Maybe its silly.....but for people who are not sure why they want to change to php5-cgi, put in a few words what could happen or what the risk is not to do only the custombuild part. I did the first part of your How To and everything was working fine, I read more posts and come to the conclusion that the users could go outside directories and use the php command readfile to read for example /etc/passwd (I know it is also bad to do a How To half....).

- Why does every user need a tmp directory? (Found the answer to this question, these are fot the sessions and tmp upload files.....am I correct?)
- Do I need to secure the tmp directory with "noexec" like the /tmp on the system?
- Can I suggest to add, as last step, to use the "./build secure_php" if wanted from custombuild.

Thanks in advance, and again great How To!

Dennis
 
Last edited:
Dennis said:
- Why does every user need a tmp directory? (Found the answer to this question, these are fot the sessions and tmp upload files.....am I correct?)
- Do I need to secure the tmp directory with "noexec" like the /tmp on the system?
Click to expand...
Each user does not need their own tmp directory for suPHP to work. I got the suggestion from getUP, but considering taking it out of the howto as like you said there is no noexec or nosuid on the per user tmp directories.
To be honest i'm not 100% sure about the security implications of having the tmp directories in the user's home directory without noexec and nosuid as from my understanding anything uploaded will be owned by the user and therefore will be a similar scenario as if uploaded via FTP etc.

Can anyone provide more of an insight to this?

Dennis said:
- Can I suggest to add, as last step, to use the "./build secure_php" if wanted from custombuild.
Click to expand...
This would be a good idea, and if any sites require some of the disabled functions, this can be overwritten in their user's php.ini
 
Last edited:
Hi Circlesquare,

Did the How To on a testserver and on a production server. Both went ok except the webmail clients. I needed to add GetUP's line to the httpd.conf:

Code: 
   <IfModule mod_suphp.c>
        suPHP_Engine On
        suPHP_UserGroup webapps webapps
        SetEnv PHP_INI_SCAN_DIR
   </IfModule>

Tou say the tmp for each user works like a FTP structure then you still need a username and password to put something in it. Are there ways to get files or even scripts in any other way?
 
Dennis said:
You say the tmp for each user works like a FTP structure then you still need a username and password to put something in it. Are there ways to get files or even scripts in any other way?
Click to expand...

Sorry, I think you misunderstood me. I mean't that because the tmp files are within the user's home directory with the user as the owner of the files, surely they will be as secure as any other scripts etc that you are permitting a user to upload to their website.

I am by no means a security professional, and would greatly appreciate some more information on this tmp directory configuration rather than a partition mounted with noexec/nosuid if anyone is able to advise?
 
You must log in or register to reply here.
Back
Top