Hi all, On 3/1/06, Kalin KOZHUHAROV <[EMAIL PROTECTED]> wrote: > Pedro Venda wrote: > > On Tuesday 28 February 2006 16:14, Ryan James R. wrote: > >> I am trying to accomplish a mass virtual hosting server where each > >> website is run from it's own user account. Now I've accomplished > >> putting the websites into user's ~/public_html directories but Apache > >> is still running as it's own user so php file managers/admin backends > >> that are run from these sites. > >> > >> I took a look at mod_userdir but I'm not sure if that's what I was wanting. > >> > >> From what I see, I think I need something that will allow apache to > >> spawn with userid of site it is serving. Please correct me if I'm > >> wrong and give as many suggestions as possible. > > > > there is more than one way to acomplish this, but none of them is perfect. > > generally you loose performance and may gain bonus security holes if you're > > not careful. > > > > * mod_suphp is the easiest and probably the best way to handle this. it > > allows > > selective php.ini configurations per vhost if you want and other nice > > restrictions. the online documentation is NOT up to date. > > > > * mod_suexec is a more generic approach. However, when me and my team of > > sysadmins needed it, we found out that it didn't work exactly as we > > expected. > > we wanted it to serve .php files with the php cgi interpreter... if I > > remember correctly, mod_suexec needed the executable bit set on scripts and > > a .cgi extension, which would seriously break our installation. Miguel > > Filipe > > - a friend of mine - wrote a one-liner patch to make it work as we needed on > > a solaris apache2 installation we were administrating at the time (around > > 8000 users).. (http://mega.ist.utl.pt/~miguel/code/) > Yes, the patch is here > http://mega.ist.utl.pt/~miguel/code/suexec+php.diff > > but just looking through the several errors in the comments and the general > hackish attitude in the code, I wouldn't recomend using it on production > servers without further auditing.
Yes, I'm not that good at english (not my native language) and I remind that the code was made because of specific issues with userdir + php + suexec in _solaris_. About the auditing, agreed, and for that same reason I also suggest you do to audit suphp code before you use it =) I did that patch exacly because I thought suphp was much more risky, having a _lot_ more code, and generally don't liking suphp code/approach. One setuid "suexec" is better than: suexec + suphp :D This shouldn't be necessary on linux since, supposedly, one should be able to execute php code under suexec if apache is properly configured. (see:http://pt.php.net/manual/en/security.cgi-bin.php for more info) Also another alternative (in linux!) is this using setting php as simple cgi scripts that should be run by suexec (http://www.fastcgi.com/archives/fastcgi-developers/2004-April/003343.html) > > Is this patch submitted to the apache team? > It looks simple enough, but as it is in a vital security area (suexec) it > may bring big surprises later. No, nor will it be, it's a hack, its advertised on the php documentation web site (http://pt.php.net/manual/en/security.cgi-bin.php#9195), and personally, I don't think the apache team even in their dreams think of adding "feature enhancements" to the suexec code... I simply tried to make the suexec + php hack a little bit more clean.. (my patch is cleaner than the code posted on http://pt.php.net/manual/en/security.cgi-bin.php#9195) Still I prefer it to suphp... which is also a hack (personal view) with a lot more lines of code.. and therefore, changes for critical bugs :D Best regards, -- Miguel Sousa Filipe -- [email protected] mailing list
