IMPORTANT: changes to /var/www/html path in CB2.0

DirectAdmin Support

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
8,500
Hello,

We'll be releasing some changes shortly, but due to their significance, some testing would be a good idea.
If you can confirm things still work, or they break, that would be appreciated.

The changes basically alter 3 settings for scripts that run in /var/www/html, we call them the webapps.
The 3 changes are:
Code: 
[PATH=/var/www/html]
session.save_path=/var/www/tmp
upload_tmp_dir=/var/www/tmp
disable_functions=exec,system,passthru,shell_exec,escapeshellarg,escapeshellcmd,proc_close,proc_open,dl,popen,show_source,posix_kill,posix_mkfifo,posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,posix_setgid,posix_seteuid,posix_setegid,posix_uname

Discussion welcome on the presence of the disable_functions... as we could omit them, which would fall-back to the main php.ini disable_functions.
Reasons for adding: I've seen some systems without any disable_functions, or some with too many, so locking down /var/www/html with a consistent set makes things a bit easier.

In any case, the changes to CB 2.0 basically create 50-webapps.ini in a path specific to your system, some examples:
Code: 
/usr/local/php55/lib/php.conf.d/50-webapps.ini
/usr/local/php53/lib/php.conf.d/50-webapps.ini
/usr/local/lib/php.conf.d/50-webapps.ini
The main requirement for the changes is the session.save_path for security reasons, which I'll not get into quite yet.

For anyone who is able to help test this, that would be greatly appreciated.
It assumes you're already using CustomBuild 2.0.

To give it a try:
Code: 
cd /usr/local/directadmin/custombuild
./build update
wget -O build http://files1.directadmin.com/services/custombuild/2.0/custombuild/build
./build rewrite_confs
which should create the mentioned 50-webapps.ini, as well as the path new /var/www/tmp path:
Code: 
drwxrwx--- 2 webapps webapps 4096 Dec 14 01:45 /var/www/tmp
but might be chgrp to apache if you're running mod_php and not mod_ruid2 (which isn't recommended, but some people do it).

If it worked, the phpinfo() output should have something like these options:
[TABLE="width: 600"]
[TR]
[TD="class: e, bgcolor: #CCCCFF"]Additional .ini files parsed[/TD]
[TD="class: v, bgcolor: #CCCCCC"]/usr/local/lib/php.conf.d/10-directadmin.ini, /usr/local/lib/php.conf.d/50-webapps.ini[/TD]
[/TR]
[/TABLE]

[TABLE="width: 600"]
[TR]
[TD="class: e, bgcolor: #CCCCFF"]session.save_path[/TD]
[TD="class: v, bgcolor: #CCCCCC"]/var/www/tmp[/TD]
[TD="class: v, bgcolor: #CCCCCC"]no value[/TD]
[/TR]
[/TABLE]

for any phpinfo() call make under /var/www/html.

For phpinfo() calls made from a /home/.../public_html, the 50-webapps.ini will still be there, but the session.save_path should be /tmp or "no value".

-----

There are similar changes coming for 1.2, but they use a different method, and we'll first get CB2.0 going to ensure the concept is correct.

John
 
I wanted to test this out but I'm still getting CB 2.0 rev1167, which doesn't have these new changes, from
Code: 
http://files1.directadmin.com/services/custombuild/2.0/custombuild/build
 
Everything seems to work okay :)
The 50-webapps.ini files are used and the /var/www/tmp path is created with webapps as user and group. RoundCube and phpMyAdmin are working properly and are using the new settings and path. Everything in /home is unaffected by these changes.
I'm running php-FPM on CentOS 7.
 
@John, It is very important that you do not force any disable_functions on regular php scripts on users accounts/domains. I do not want to debate it, but I consider this a false security, and we do not have any disable_functions in php.ini - it is very important that this is not forced upon us.

As long as the disable_functions only is added for the webapps and not affect anything else, and any users sites is still without disable_functions, then it is fine by me. But do not force this upon anything else then the webapps like phpMyAdmin and Rouncuce etc. We do not want to have ANY disable_functions on any php scripts on user accounts domains! Thanks.

Edit: Also please do not change the tmp directory used by sites for user accounts domains, and do not force disable_functions on those.
 
Last edited:
I don't find disable_functions false security, but I agree not to force setting any disable_functions in php.ini because it may break several scripts.
For example I can't use a certain well known internet radio script when certain disable_functions are set.

If it's only done for the webapps and does not effect anything else like Ditto says, it's oke by me too.

Next to that we symlinked our temp directory's to a noexec protected /tmp directory. I'm not sure why you want to create another one and don't use the default one?
 
Don't worry, as John described, these changes only have an effect on the webapps (/var/www/html) and not the regular users' domains (/home).
 
Right, that should affect only scripts located in /var/www/html. And as additional 50-webapps.ini is used for these changes the main php.ini will be stayed without modification.

[PATH=<path>]

This section allows you to define a set of php.ini directives that will take effect when a script runs from the named path.

Example #2 Add security script for protected areas

Code: 
[PATH=/home/site/public/secure]
auto_prepend_file=security.php
Click to expand...

http://php.net/manual/en/ini.sections.php#ini.per-path


Good idea, and I like it.
 
Richard G said:
Next to that we symlinked our temp directory's to a noexec protected /tmp directory. I'm not sure why you want to create another one and don't use the default one?
Click to expand...
Not using /tmp is the whole reason for the change. It relates to a security issue with SquirrelMail sessions. As SM development is not terribly active, this is why we opted to implement the workaround. If you link /var/www/tmp to /tmp, it would completely defeat the purpose of these changes (SM session tmp must not be a+rx).
The value for upload_tmp_dir is not as relevant to the fix, so if you want to keep that in /tmp, you can.

Because the 50-webapps.ini might not be perfect for everyone, I've added the ability to use this override, into CB2.0:
Code: 
/usr/local/directadmin/custombuild/custom/php.conf.d/50-webapps.ini
which will be copied over, instead of the text, above.

And to clarify, as others already have, this should only affect scripts in /var/www/html.
Everything else outsdie of /var/www/html should not be untouched.
I wouldn't do that to you :)

CustomBuild 2.0 has now been updated on files1.

John
 
@John, I just upgraded from PHP 5.6.3 to PHP 5.6.4 and before upgrade of PHP a php-info page on the server displayed this:

Code: 
Directive	Local Value	Master Value
upload_tmp_dir	no value	no value

However after upgrade to PHP 5.6.4 a php-info page on the server displayed this:

Code: 
Directive	Local Value	Master Value
upload_tmp_dir	/var/www/tmp	no value

So my big question then is if the new Local Value of /var/www/tmp will affect regular php sites on users domain or not? If so I don't like that. Because I want to use my servers /tmp like before.

Edit: Also is it now needed to do a ./build rewrite_confs in order for everything to funtion correct?

Edit2: Also should we now secure /var/www/tmp by mounting it with nosuid,noexec, like I have done with server main /tmp? Or will that break webapps?

I am not happy with the changes, because I was happy with it the way it was before.
 
Last edited:
I'm waiting with updating php because I'm not sure what's going to happen, maybe it's an idea to create RC versions of changes in CB 2.0 like this? I'm aware that CB 2.0 is in beta, but many people are using it for production.
 
ditto said:
@John, I just upgraded from PHP 5.6.3 to PHP 5.6.4 and before upgrade of PHP a php-info page on the server displayed this:

Code: 
Directive    Local Value    Master Value
upload_tmp_dir    no value    no value

However after upgrade to PHP 5.6.4 a php-info page on the server displayed this:

Code: 
Directive    Local Value    Master Value
upload_tmp_dir    /var/www/tmp    no value

So my big question then is if the new Local Value of /var/www/tmp will affect regular php sites on users domain or not? If so I don't like that. Because I want to use my servers /tmp like before.

Edit: Also is it now needed to do a ./build rewrite_confs in order for everything to funtion correct?

Edit2: Also should we now secure /var/www/tmp by mounting it with nosuid,noexec, like I have done with server main /tmp? Or will that break webapps?

I am not happy with the changes, because I was happy with it the way it was before.
Click to expand...

This is a local value of /var/www/html, because you have your phpinfo page located there :) Please upload phpinfo to any of your websites, and you'll see the value they have set.
 
After update this, I get the below error when import mysql database:

Uploaded file cannot be moved, because the server has open_basedir enabled without access to the /var/www/tmp directory (for temporary files).
Click to expand...
 
@smtalk, thank you. I can confirm that previous phpinfo page I looked at was located at the server hostname. I tested a phpinfo page on a regular domain, and the "local value" of "upload_tmp_dir" has "no value" (like it used to be). Great.

Also I can confirm that import of .sql files using phpMyAdmin still works for me after upgrade. I am running mod_php with mod_ruid2

Should I do ./build rewrite_confs after upgrade of php this time, in order to get some needed changes regarding the new /var/www/tmp directory?
 
Please edit your /usr/local/php5*/etc/php-fpm.conf file, comment out open_basedir line (add ";" to the beginning of the line) and restart php-fpm service :) That should solve the problem.
 
DirectAdmin Support said:
Not using /tmp is the whole reason for the change. It relates to a security issue with SquirrelMail sessions. As SM development is not terribly active, this is why we opted to implement the workaround. If you link /var/www/tmp to /tmp, it would completely defeat the purpose of these changes (SM session tmp must not be a+rx).
The value for upload_tmp_dir is not as relevant to the fix, so if you want to keep that in /tmp, you can.

Because the 50-webapps.ini might not be perfect for everyone, I've added the ability to use this override, into CB2.0:
Code: 
/usr/local/directadmin/custombuild/custom/php.conf.d/50-webapps.ini
which will be copied over, instead of the text, above.

And to clarify, as others already have, this should only affect scripts in /var/www/html.
Everything else outsdie of /var/www/html should not be untouched.
I wouldn't do that to you :)

CustomBuild 2.0 has now been updated on files1.

John
Click to expand...

I agree with Richard, /tmp is mounted with noexec for security reasons. Why create a new tmp directory for the webapps? Nobody can guarantee Roundcube/phpmyadmin/other webapps are 100% secure and will never be abused to place an executable in /var/www/tmp.

I read your answer about SM which I do not totally understand, but is SM still supported by DA? If yes: why not put it out of support as there are other better, more secure, webmail clients and so you don't need to create a very non-secure workaround. If SM is already unsupported why implement this change resulting in a security hole for the other webapps. Maybe the workaround could better be "disable SM".
 
You must log in or register to reply here.
Back
Top