I have a problem that I failed to notice since upgrading to 2.2.21 with suphps open base dir and roundcubemail. My roundcube install now sports in the vhosts for apache2. Code: <Directory /var/www/web#/web> suPHP_Engine on suPHP_UserGroup web#_user web# AddHandler x-httpd-php .php .php3 .php4 .php5 suPHP_AddHandler x-httpd-php SetEnv php_safe_mode Off </Directory> before 2.2.21 in the vhosts for apache2 Code: suPHP_Engine on suPHP_UserGroup web#_user web# AddHandler x-httpd-php .php .php3 .php4 .php5 suPHP_AddHandler x-httpd-php Now I am not able to login with any newly created email addresses. Code: PHP Warning: is_file() [<a href='function.is-file'>function.is-file</a>]: open_basedir restriction in effect. File(/etc/postfix/virtusertable) is not within the allowed path(s): (/var/www/web#) in /var/www/web#/web/program/include/main.inc on line 680 I never noticed since I could still login with previous used email users I am guessing cause their names were in the roundcube database already. Any ideas on how remove the open base dir restriction for the web or make /etc/postfix/virtusertable accessible to the web. Thanks Dave
@Dave, Do you have the next two lines within you RoundCube config/main.inc.php configuration file? $rcmail_config['auto_create_user'] = TRUE; $rcmail_config['virtuser_file'] = '/etc/postfix/virtusertable';
yes I do, I have been using it like this for some time. Never noticed anything changed untill the other day. I added a few new webs and I was informed by the clients that they could not login to webmail. after looking into this I found it was due to new open_basedir restriction with suphp since 2.2.20. Now just need to come up with a fix for my prob. I have a tmp solution in place untill I can come up with something perm.
I have been having the same problem, I'd be interested to hear peoples solution to this. My fix at the moment has been to make a copy of /etc/postfix/virtusertable to the web where roundcube is hosted e.g. /var/www/webX/virtusertable and change the owner to that webs owner and chmod it to 400. I then updated RoundCube config/main.inc.php to the new virtusertable location. My rationale behind this was that it is a world-readable file anyway. It doe's have every user name in so it is a little sensitive at least. It is below the web root so isn't readable by the general public. The system admin should be the only person with access to this web. One downside of this method is that it must be updated each time virtusertable changes, this could be done via a cron job or perhaps incorporated into the ISPConfig script that triggers when users/email aliases change. The other way I thought of was to use a custom open_basedir for this web via a custom php.ini. I did try this but it seemed the file still needed to be owned by the web owner to work. Maybe I set this up wrong. Anyones thoughts as to the security of the 1st method and any other methods possible would be great to hear. edit: if anyone can shed some light on where these extra line breaks come from it'd be appreciated! Using Ubuntu.
Well, i have to say that i use RC 0,1 stable with php5-cgi+ suphp on my two production servers and i don't have any problem with login sessions. Do you see any related errors within the logs directory which comes with RoundCube?
@hans I didnt have any problem either till I created new users and they wernt in the rcmail db yet. I know what is causing the issue and its the suphp wrapper Code: /home/admispconfig/ispconfig/tools/suphp/usr/bin/php-wrapper new in 2.2.20+ setting the basedir restriction to /var/www/web#. Code: PHP Warning: is_file() [<a href='function.is-file'>function.is-file</a>]: open_basedir restriction in effect. File(/etc/postfix/virtusertable) is not within the allowed path(s): (/var/www/web#) in /var/www/web#/web/program/include/main.inc on line 680 I like the added security of the open basedir being set I just wonder how I could change that for 1 web. I also for a tmp solution copied the virtusertable to a place the web can reach. I would like to find a more permanent solution.
@Hans I was getting the same errors as daveb, warning of open_basedir in effect. My install of Roundcube 0.1 was done as per your howto, it was on a totally fresh 2.2.21 install. So all my users have been new as it were. It all works fine, except for logins using an email address. Thanks for your howto. @daveb I've managed to get an individual php.ini working for my server, the main problem is open_basedir can only be declared once it seems and all further entries are ignored, so any set in a custom php.ini get ignored. This is for security I believe so it can't be got around further down the chain of .ini files. The only way for it to work is to remove the open_basedir parts from the suphp wrapper. This means that you must create a php.ini for every web with php enabled along with open_basedir settings for each web to keep the protection. I got the suPHP custom php.ini bit from here As in that thread it would be necessary to hack the make_vhost function in /root/ispconfig/scripts/lib/config.lib.php. I think this gets overwritten on an update, so it is a bit more work to maintain compared to copying the virtusertable perhaps with cron. Both ways don't seem ideal. I'll write up the custom php.ini steps in a bit more detail once I get the config.lib.php bit sorted.
@Daveb & Toolish, I understand your problem. But what i don't understand is that i don't have a similar problem! I'am using suphp as well with ISPConfig 2.2.21 on Debian Etch. When i create new users, they can login with e-mailaddress AND username as defined within ISPConfig.
I am using the suphp.conf file /etc/suphp.conf. That one came with ISPConfig 2.2.20+, the original one was copied within /etc marked with a time stamp. Are you sure that you've taken all the steps for your Linux distribution as described here: http://www.howtoforge.com/install-s...tions-for-use-with-ispconfig-2.2.20-and-above
actualy hans I used your howto awhile back for suphp. I also already tried to set a open_basedir in a custom php.ini file for that web and the open_basedir still gets over written to /var/www/web#. /etc/suphp.conf Code: [global] ;Path to logfile logfile=/var/log/suphp.log ;Loglevel loglevel=info ;User Apache is running as webserver_user=www-data ;Path all scripts have to be in docroot=/ ;Path to chroot() to before executing script ;chroot=/mychroot ; Security options allow_file_group_writeable=true allow_file_others_writeable=false allow_directory_group_writeable=true allow_directory_others_writeable=false ;Check wheter script is within DOCUMENT_ROOT check_vhost_docroot=true ;Send minor error messages to browser errors_to_browser=false ;PATH environment variable env_path=/bin:/usr/bin ;Umask to set, specify in octal notation umask=0022 ; Minimum UID min_uid=100 ; Minimum GID min_gid=100 [handlers] ;Handler for php-scripts x-httpd-php=php:/home/admispconfig/ispconfig/tools/suphp/usr/bin/php-wrapper ;Handler for CGI-scripts x-suphp-cgi=execute:!self And here is the php-wrapper Code: #!/bin/sh PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/libexec" BASEDIR=`dirname ${DOCUMENT_ROOT}` TMPDIR=${BASEDIR}/phptmp SESSDIR=${TMPDIR} if [ X"${php_safe_mode}" != X"On" ]; then SAFE_MODE="Off" else SAFE_MODE="On" fi exec php-cgi -d open_basedir=${BASEDIR} -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE} Is "BASEDIR=`dirname ${DOCUMENT_ROOT}`" being read from the ispconfig database or php.ini I guess is my question?
Ok, i created my howto before the release of ISPConfig 2.2.20. Within my howto, i described to do the following before compilation: Within the file: src/apache2/mod_suphp.c: Replace the lines 324/325 with these two lines below (if you use a different version of suPHP, the line numbers can be different): AP_INIT_ITERATE("suPHP_AddHandler", suphp_handle_cmd_add_handler, NULL, RSRC_CONF | ACCESS_CONF, "Tells mod_suphp to handle these MIME-types"), AP_INIT_ITERATE("suPHP_RemoveHandler", suphp_handle_cmd_remove_handler, NULL, RSRC_CONF | ACCESS_CONF, "Tells mod_suphp not to handle these MIME-types"), This is not necesarry anymore since ISPConfig 2.2.20 and the reason that Falko does not mention it within his howto. You can consider to take step 1 again for your Debian distro as decribed within Falko's howto here: http://www.howtoforge.com/install-s...tions-for-use-with-ispconfig-2.2.20-and-above. It will not harm your system.
I had a feeling I may have also followed your howto Hans. I just re-installed suPHP as per your link, version 0.6.3 now. I still get the same error of open_basedir restriction being in effect. Do you have anything in Code: $rcmail_config['virtuser_query'] = ''; for your Roundcube main.inc.php?
It's certainly very strange. I would have thought open_basedir should restrict access to directories like /etc/postfix. It seems though for you Hans that it does not. On my system (Debian Etch) unless I take one of the steps above its actually any user that is unable to login with an email. Not just new to the Roundcube system users as I had said earlier. Should Roundcube be storing the aliases in its own database or does it get them fresh everytime from virtusertable?
RoundCube reads users/e-mailaddresses within the /etc/postfix/virtusertable so they can login with their username+password AND e-mailaddress AND password. RoundCube creates the username of the user after a first login in it's own database as well. The following lines within the config/main.inc.php file are responsible for this behaviour: $rcmail_config['auto_create_user'] = TRUE; $rcmail_config['virtuser_file'] = '/etc/postfix/virtusertable';
@Daveb, I don't have any value set for "open_basedir" within my php configuration. I think suPHP and open_basedir don't like eachother that much! Probably, you can specify a custom php.ini file for suphp in the apache directives field of the website and then set a php open basedir value for the website that prevents file system browsing.
@Hans I am lost hahaha. I have already tried that and currently still using a custom php.ini. I setup a php.ini for that web and set in apache directives to use it. when I tested via php info I could see that it was using the correct php.ini. But its open_basedir vaule still ends up as the webs doc root. I belive it is due to the way the php wrapper is exec php. as you can see from post 11. Qusetion is the php wrapper ${DOCUMENT_ROOT} now where is that from php.ini or ispconfig or apache vhosts.
Hi Daveb, According Falko, ISPConfig 2.2.20 and up uses /etc/suphp.conf (witten by ISPConfig) Please have a look here: http://www.howtoforge.com/forums/showthread.php?t=20469 thread number (4 till 7)
I think the ${DOCUMENT_ROOT} is an Apache/PHP environment variable, set in Vhosts_ispconfig.conf. I think open_basedir can't be overwritten further down the chain otherwise it would be possible to overwrite it in an .htaccess file. This is for security I think. The php-wrapper script does pull php_safe_mode off of Vhosts_ispconfig.conf and it is possible to set extra environmental variables this way. So I'm thinking you could add 'SetEnv custom_php_ini On/Off' as is done for safe_mode and then have the php-wrapper script detect this and then drop the open_basedir from the php-cgi command if set to 'On' and be as normal for 'Off', so it can be overwritten in the php.ini. Will work on a patch, ideally it would be nice to have on a option in the control panel to be able to set custom php.ini per web.
