httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Andrew Misel <steve.mi...@interpath.net>
Subject Setuid Apache?
Date Mon, 15 Nov 1999 12:42:45 GMT
Good morning.

I've developed a patch for 1.3.9 which will allow it to execute CGI's and serve
documents as the user the request came in for.

My new Apache has the SuEXEC User and Group directives enabled in httpd.conf but
instead of calling a wrapper for CGI's and serving documents as root or nobody, it
uses the User and Group directives to assume that user's identity to handle the
request.

The processes wait for connections as root, and once a connection has been made, it
calls setegid() and seteuid() for the User and Group specified in the conf file for
that VirtualHost.  If the request is a non CGI (or SSI, etc) the request is handled
and that process does a setegid() and seteuid() back to root to wait for the next
request.

In the event we're dealing with a CGI and need to fork(), the setegid() and
seteuid() are back to root, at which point it calls setgid() and setuid() to assume
the user's real identity (verses effective), and then forks off the child.  Of
course, when the request is complete, it assumes root again and waits in the free
pool.

I see the security implications here as minimal, as long as the server makes a
confirmation that it's uid/gid change was successful before serving documents or
running CGI's (otherwise they'd run as root, bad bad).  Am I correct?

I've been running this on development servers (Enterprise 450's) for some time on
both Apache 1.3.9 and StrongHold 2.4.2 with no problems.  Also, mod_frontpage (I
know how little we like to talk about it!) works flawlessly in this scenario.  It's
like each customer gets as many apache processes as they need, all running as them.
Also, I thought it was pretty spiffy to watch the processes with ps.  I can see them
running as root, and when they handle a request, they run as someone else.  When
it's done, they're root again, hanging out waiting on another request.

If there's significant interest, I can clean up my code a little bit (we're talking
about ~10 lines) and post it here.

Note that I've only tested this with HTTP/1.0 IP-based virtual-hosting.  I don't see
any reason why it wouldn't work with the 1.1 stuff, but since I only use IP hosting,
I haven't tested it.

In a situation such as this, does anyone think any aspect of Apache could be
broken?   Perhaps I'm overlooking something?  Are there any additional security
concerns to watch out for?  If it looks like a good idea, why isn't there already a
patch for it?  :)

-Steve

Interpath Communications, Inc.
Raleigh, North Carolina


Mime
View raw message