Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User BasedProcesses (SuExec) + Chroot

--_57ca86fe-6555-420e-80ee-bbad536bc9dd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I was referred to this mailing list from the following thread on perlmonks =
(http://www.perlmonks.org/index.pl?node_id=3D693487)
=20
==================== =====3D=
==========
=20
For years I have been using modperl and have been quite fond of it, the ide=
a of persistant perl interpereter is excellent.The problem however lies wit=
h using modperl securely for multiple sites. Ideally, the desired solution =
is to have each site run in a chroot jail for security, have each site exec=
ute under it's own user/group and have a modperl instance for each site.Up =
until now the best solution I have been able to come up with is as follows:=
Implementation 1:=20
Top Level Apache Server, Port 80, ModProxy=20
This serves requests via ModProxy to the respective apache servers with mod=
_perl.Site 1 Apache Server, Port 8081, ModPerl=20
This server runs an instance of ModPerl and all scripts required for Site 1=
..Apache User: site1Site 2 Apache Server, Port 8082, ModPerl=20
This server runs an instance of ModPerl and all scripts required for Site 2=
..Apache User: site2This allowed me to have seperate modperl instances, this=
is done for three reasons:=20
1) ModPerl does not support user based processes2) This prevents pollution =
between instances & secures one mod_perl instance from another.3) Each inst=
ance can be chrooted for additional security.The problem with this configur=
ation is:=20
1) Requires a new http server for each additional site/modperl application2=
) Apache creates a set of workers for each instance (ususally about 7). Wit=
h 7 required for the Top level proxy, and 7 for each site, this soon adds u=
p.=20
e.g. 5 sites =3D 7 + (5 * 7) =3D 49 child workers--------------------------=
-------Implementation 2:A new solution I have been working on is to have a =
single Apache server with chrooting suexec and speedycgi.The setup is as fo=
llows:=20
1. Create a Chroot Jail for Apache (Extra Security Measure). 2. Modify suEx=
ec to allow chrooting before suid and process execution.3. Install Apache i=
nto Chroot Jail4. For each site:
a. Create a Jail for each site that includes perl + speedycgib. Create a vi=
rtualhost which specifies SuExecUserGroup and the ENV variable used for the=
chroot.How it works:=20
Apache first resides in a jail, it then serves non-perl requests to static =
objects as per normal. When a request for a perl script is made:=20
Apache chroots into the site's jail using suexec. Suexec changes to the cor=
rect site's user.SpeedyCGI then either:
Loads a script into speedy-backend orExecutes a script cached in speedy-bac=
kendAdvantages:=20
1) Provides persistant perl WITH suexec for per-virtualhost user execution2=
) SpeedyCGI handles dynamic data, Apache handles static, hence you don't re=
quire a covering proxy as described in http://perl.apache.org/docs/1.0/guid=
e/strategy.html3) The timeout property in speedycgi means that a script wit=
h low or no load will drop out of memory, this means high use scripts will =
run in persistant perl and low use scripts will load into memory then remov=
e themself when they are no longer being activly used. Disadvantages:=20
1) Speedycgi seems to be no longer in development, whereas modperl is still=
in active development.2) I have read somewhere that speedycgi is not as fa=
st as modperl (will have to benchmark the two later).3) Since speedycgi wit=
h timeout enabled fades out with inactivity, the first request to an inacti=
ve script requires all the modules to be reloaded, whereas modperl exists i=
n memory indefinitly and can load a script on server start, rather than fir=
st request. ---------------------------------I was wondering if I could get=
some feedback on both these designs. I have been researching and testing t=
he second solution over the last few days and would like to get some input.=
a) Is there a better way to achive this goal?b) Is there a way to make modp=
erl scale and attain the desired results without creating a new server for =
each instance (Implementation 1)?c) Have I missed anything (security etc. (=
Implementation 2))?d) Is there a better solution (fastcgi/pperl etc.)?e) Wh=
at are there any downsides (other than those listed above) to either of the=
se implementations?Finally, are there any suggestions/ideas?James Austin=20
____________________________________________________________ _____
Never miss another e-mail with Hotmail on your mobile.
http://www.livelife.ninemsn.com.au/article.aspx?id=3D343869=

--_57ca86fe-6555-420e-80ee-bbad536bc9dd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





I was referred to this mailing list from the foll=
owing thread on perlmonks ( e_id=3D693487">http://www.perlmonks.org/index.pl?node_id=3D6 93487)

==================== =====
===========3D

For years I have been using modperl and have been quite fond of it, the =
idea of persistant perl interpereter is excellent.

The problem howev=
er lies with using modperl securely for multiple sites. Ideally, the desire=
d solution is to have each site run in a chroot jail for security, have eac=
h site execute under it's own user/group and have a modperl instance for ea=
ch site.

Up until now the best solution I have been able to come up =
with is as follows:

Implementation 1:=20

Top Level Apache Server, Port 80, ModProxy=20

This serves requests via ModProxy to the respective apache serv=
ers with mod_perl.

Site 1 Apache Server, Port 8081, ModPerl=20

This server runs an instance of ModPerl and all scripts require=
d for Site 1.
Apache User: site1

Site 2 Apache Server, Port =
8082, ModPerl=20

This server runs an instance of ModPerl and all scripts require=
d for Site 2.
Apache User: site2

1) ModPerl does not support user based processes
2) This pre=
vents pollution between instances & secures one mod_perl instance from =
another.
3) Each instance can be chrooted for additional security.
BLOCKQUOTE>The problem with this configuration is:=20

1) Requires a new http server for each additional site/modperl =
application
2) Apache creates a set of workers for each instance (ususal=
ly about 7). With 7 required for the Top level proxy, and 7 for each site, =
this soon adds up.=20

e.g. 5 sites =3D 7 + (5 * 7) =3D 49 child workers

<=
/BLOCKQUOTE>---------------------------------

Implementation 2: B>
A new solution I have been working on is to have a single Apache serv=
er with chrooting suexec and speedycgi.

The setup is as follows:=20

1. Create a Chroot Jail for Apache (Extra Security Measure). 2.=
Modify suExec to allow chrooting before suid and process execution.
3. =
Install Apache into Chroot Jail
4. For each site:

a. Create a Jail for each site that includes perl + speedycgi R>b. Create a virtualhost which specifies SuExecUserGroup and the ENV varia=
ble used for the chroot.

How it works:=20

Apache first resides in a jail, it then serves non-perl request=
s to static objects as per normal. When a request for a perl script is made=
:=20

Apache chroots into the site's jail using suexec. Suexec change=
s to the correct site's user.
SpeedyCGI then either:

Loads a script into speedy-backend or
Executes a script cach=
ed in speedy-backend

Advantages:=20

1) Provides persistant perl WITH suexec for per-virtualhost use=
r execution
2) SpeedyCGI handles dynamic data, Apache handles static, he=
nce you don't require a covering proxy as described in http://perl.apache.o=
rg/docs/1.0/guide/strategy.html
3) The timeout property in speedycgi mea=
ns that a script with low or no load will drop out of memory, this means hi=
gh use scripts will run in persistant perl and low use scripts will load in=
to memory then remove themself when they are no longer being activly used. =

Disadvantages:=20

1) Speedycgi seems to be no longer in development, whereas modp=
erl is still in active development.
2) I have read somewhere that speedy=
cgi is not as fast as modperl (will have to benchmark the two later).
3)=
Since speedycgi with timeout enabled fades out with inactivity, the first =
request to an inactive script requires all the modules to be reloaded, wher=
eas modperl exists in memory indefinitly and can load a script on server st=
art, rather than first request.

------------------------------=
---

I was wondering if I could get some feedback on both these desig=
ns. I have been researching and testing the second solution over the last f=
ew days and would like to get some input.

a) Is there a better way t=
o achive this goal?
b) Is there a way to make modperl scale and attain t=
he desired results without creating a new server for each instance (Impleme=
ntation 1)?
c) Have I missed anything (security etc. (Implementation 2))=
?
d) Is there a better solution (fastcgi/pperl etc.)?
e) What are the=
re any downsides (other than those listed above) to either of these impleme=
ntations?

Finally, are there any suggestions/ideas?

Jame=
s Austin

---

Hotmail on your mobile. ..ninemsn.com.au/article.aspx?id=3D343869' target=3D'_new'>Never miss anothe=
r e-mail with
=

--_57ca86fe-6555-420e-80ee-bbad536bc9dd_--