1 |
Hi all, |
2 |
|
3 |
On 3/1/06, Kalin KOZHUHAROV <kalin@××××××××.net> wrote: |
4 |
> Pedro Venda wrote: |
5 |
> > On Tuesday 28 February 2006 16:14, Ryan James R. wrote: |
6 |
> >> I am trying to accomplish a mass virtual hosting server where each |
7 |
> >> website is run from it's own user account. Now I've accomplished |
8 |
> >> putting the websites into user's ~/public_html directories but Apache |
9 |
> >> is still running as it's own user so php file managers/admin backends |
10 |
> >> that are run from these sites. |
11 |
> >> |
12 |
> >> I took a look at mod_userdir but I'm not sure if that's what I was wanting. |
13 |
> >> |
14 |
> >> From what I see, I think I need something that will allow apache to |
15 |
> >> spawn with userid of site it is serving. Please correct me if I'm |
16 |
> >> wrong and give as many suggestions as possible. |
17 |
> > |
18 |
> > there is more than one way to acomplish this, but none of them is perfect. |
19 |
> > generally you loose performance and may gain bonus security holes if you're |
20 |
> > not careful. |
21 |
> > |
22 |
> > * mod_suphp is the easiest and probably the best way to handle this. it allows |
23 |
> > selective php.ini configurations per vhost if you want and other nice |
24 |
> > restrictions. the online documentation is NOT up to date. |
25 |
> > |
26 |
> > * mod_suexec is a more generic approach. However, when me and my team of |
27 |
> > sysadmins needed it, we found out that it didn't work exactly as we expected. |
28 |
> > we wanted it to serve .php files with the php cgi interpreter... if I |
29 |
> > remember correctly, mod_suexec needed the executable bit set on scripts and |
30 |
> > a .cgi extension, which would seriously break our installation. Miguel Filipe |
31 |
> > - a friend of mine - wrote a one-liner patch to make it work as we needed on |
32 |
> > a solaris apache2 installation we were administrating at the time (around |
33 |
> > 8000 users).. (http://mega.ist.utl.pt/~miguel/code/) |
34 |
> Yes, the patch is here |
35 |
> http://mega.ist.utl.pt/~miguel/code/suexec+php.diff |
36 |
> |
37 |
> but just looking through the several errors in the comments and the general |
38 |
> hackish attitude in the code, I wouldn't recomend using it on production |
39 |
> servers without further auditing. |
40 |
|
41 |
Yes, I'm not that good at english (not my native language) and I |
42 |
remind that the code was made because of specific issues with userdir |
43 |
+ php + suexec in _solaris_. |
44 |
About the auditing, agreed, and for that same reason I also suggest |
45 |
you do to audit suphp code before you use it =) |
46 |
I did that patch exacly because I thought suphp was much more risky, |
47 |
having a _lot_ more code, and generally don't liking suphp |
48 |
code/approach. |
49 |
|
50 |
One setuid "suexec" is better than: suexec + suphp :D |
51 |
|
52 |
This shouldn't be necessary on linux since, supposedly, one should be |
53 |
able to execute php code under suexec if apache is properly |
54 |
configured. (see:http://pt.php.net/manual/en/security.cgi-bin.php for |
55 |
more info) |
56 |
|
57 |
Also another alternative (in linux!) is this using setting php as |
58 |
simple cgi scripts that should be run by suexec |
59 |
(http://www.fastcgi.com/archives/fastcgi-developers/2004-April/003343.html) |
60 |
|
61 |
|
62 |
> |
63 |
> Is this patch submitted to the apache team? |
64 |
> It looks simple enough, but as it is in a vital security area (suexec) it |
65 |
> may bring big surprises later. |
66 |
|
67 |
No, nor will it be, it's a hack, its advertised on the php |
68 |
documentation web site |
69 |
(http://pt.php.net/manual/en/security.cgi-bin.php#9195), and |
70 |
personally, I don't think the apache team even in their dreams think |
71 |
of adding "feature enhancements" to the suexec code... |
72 |
|
73 |
I simply tried to make the suexec + php hack a little bit more clean.. |
74 |
(my patch is cleaner than the code posted on |
75 |
http://pt.php.net/manual/en/security.cgi-bin.php#9195) |
76 |
|
77 |
Still I prefer it to suphp... which is also a hack (personal view) |
78 |
with a lot more lines of code.. and therefore, changes for critical |
79 |
bugs :D |
80 |
|
81 |
Best regards, |
82 |
|
83 |
-- |
84 |
Miguel Sousa Filipe |
85 |
|
86 |
-- |
87 |
gentoo-server@g.o mailing list |