Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jan 2010 13:05:05 -0500
From:      Nathan Vidican <>
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
Check out suExec, (assuming you're using Apache)...

Please see:   and/or

You can make an entire VirtualHost directive run as a different user/group.

Nathan Vidican

On Fri, Jan 22, 2010 at 12:57 PM, DAve <> wrote:

> Matthew Seaman wrote:
> > 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 they
> >> 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
> nothing
> > to stop them reading /etc/passwd.  They are essentially the same level of
> > risk as an unprivileged user login account.
> > 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
> > interpreter
> > embedded in the apache process: they can access anything accessible to
> the
> > web server process.
> > 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
> > install of apache etc. certainly does work, it implies dedicating at
> least
> > an IP per customer.  You could avoid that by still keeping a single
> > apache instance but use something like an fCGI process per customer
> > running each in separate jails hanging off the loopback i/f.
> All understood. I have had the conversation before with the PHB about
> the accessibility of /etc/passwd and the rest of the system. Our PHP
> instance is well locked down and they cannot do much harm, but I still
> have to audit periodically, if just for my own peace of mind.
> I suspected there was no new tool or wrapper to further secure a CGI
> process beyond chrooting it or putting the entire site within a it's own
> jail. But.. I have to look and ask because I WILL be asked if I did.
> Thanks for the response.
> DAve
> --
> "Posterity, you will know how much it cost the present generation to
> preserve your freedom.  I hope you will make good use of it.  If you
> do not, I shall repent in heaven that ever I took half the pains to
> preserve it." John Adams
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to "

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