httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Tao <>
Subject Re: Question for the development team
Date Sun, 17 Aug 1997 16:23:28 GMT
On Wed, 13 Aug 1997, Randy Terbush wrote:
> suEXEC currently doesn't do a chroot() for CGI execution. There are 
> several reasons that we did not take this extra step.
> 1. chroot() environments are not easy to setup

    No, and what's worse is that getting it right is different for
every flavour of UNIX.  Having said that, anyone who has set up a
typical anonymous FTP service will have most (if not all) of a working
chroot environment.  I'd hate to see useful functionality left out of
Apache because we think most people will fumble around cluelessly if
they try to use it.  Put big warnings around it or something.

> 2. CGI often wants access to other tools outside of the local
>    directory which would make it rather difficult to setup.

    True, but again it is up to the admin to correctly configure the
environment, and not Apache's place to limit what the admin wants to
do.  I'd rather take my chances on having a CGI break in a chroot jail
than not having the chance at all.

> 3. suEXEC already limits execution of CGI to a compiled in 
>    DOCUMENTROOT which offers _some_ of the benefit of a chroot() 
>    without the hassle.

    I can't change DOCUMENTROOT on a per virtual server basis, which
makes it useless in my situation.  My situation:  customers currently
have chrooted FTP (with login/paassword) and qpopper access to our
hosting servers.  All services they can use (HTTP, FTP, POP3) are
chrooted to their home directory.  I don't want to break this policy
for those who want CGI's.

    In any case, a suexec'd CGI still has visibility of the entire
filesystem (including the directories of other virtual domains), and
can write to areas like /tmp.

> 4. suEXEC runs the CGI as the defined owner of the file. *In 
>    Theory* the CGI being executed can only do as much damage as 
>    that user has privledges to do.

    ... and we all know how many recent root exploits have been
recently reported possible with an unprivileged account.  :(  You
might as well give CGI users a shell account on your system.

> It is all a matter of degree of risk. In a more hostile environment,
> it may very well be worth making the changes to run in a chroot'ed
> environment.

    Is anyone considering putting in chroot() functionality into
suexec?  Alternatively, are there other existing wrappers that can
perform the same function?  I like all the other checks suexec
performs though.  If it could chroot() before running the CGI, it
would be perfect.
Brian Tao (BT300,
"Though this be madness, yet there is method in't"

View raw message