Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jan 2010 17:14:47 +0000
From:      Matthew Seaman <>
To:        DAve <>
Cc:        'User Questions' <>
Subject:   Re: Securing cgi scripts
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

DAve wrote:
> Good morning all,
> I have been working on an issue here where I am being asked if we can
> support letting clients install and run their own CGI scripts on a
> shared vhost. I have tried sbox and cgiwrap, both which worked, but the=
> cannot stop the one test of reading the /etc/passwd file.
> Forgive my ignorance here, but I thought CGIs were gone long ago and
> have not messed with them in over ten years. If a client really needs a=

> specfic CGI script hosted, I check it out thoroughly and install it
> where they cannot reach it. Those instances are very very rare.
> It looks to me like the only way to keep a client contained is to run
> their CGIs chrooted. Would this be correct?

CGI programs run in the OS filesystem context, so there's generally nothi=
to stop them reading /etc/passwd.  They are essentially the same level of=

risk as an unprivileged user login account. =20

Mind you, pretty exactly the same thing applies if you let your customers=

supply their own PHP or perl or other programs which run using an interpr=
embedded in the apache process: they can access anything accessible to th=
web server process. =20

I should point out that unprivileged users are *meant* to be able to
read /etc/passwd -- it's /etc/master.passwd that has the sensitive stuff
in it.

In fact, the bigger problem with running CGI programs from a shared
webserver is that they generally all run using the same security
credentials; those of the web server (www:www by default) -- which
potentially lets all your different customers tread on each others toes. =
 suexec(8) is the stock solution to that problem.

If you really want to keep your customers properly separated, then send
them to jail(8).  While giving them each a separate jail with a full=20
install of apache etc. certainly does work, it implies dedicating at leas=
an IP per customer.  You could avoid that by still keeping a single apach=
instance but use something like an fCGI process per customer running each=
separate jails hanging off the loopback i/f.



Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP:     Ramsgate
                                                  Kent, CT11 9PW

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla -



Want to link to this message? Use this URL: <>