httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason A. Dour" <>
Subject suEXEC, son of suCGI.
Date Mon, 29 Jul 1996 12:23:28 GMT

Well, Randy and I are at a mid-point in the development of suEXEC.  So, we
thought we'd submit it for your perusal.  I've attached suexec.c and
suexec.patch to this letter.  That patch should apply cleanly to the
current dev version.  If it doesn't you'll have to speak with Randy about
that.  8)

Our primary goals for suEXEC were:
	* To have su behaviour per VirtualHost
	* To have su behaviour per UserDir
	* To have su behaviour per Directory
	* To have su behaviour per Location

With this version of suEXEC, we've attained the first two of our goals. 
Before we began delving into the dark depths of per/dir configs, we
thought we'd ask for comments, kisses, questions, hugs, et cetera from the
group.  8)

Our current design for suEXEC is a little different than the original
suCGI.  We've removed (for the time being) all of the internal paranoia
checks.  At present, all paranoia checks are done by the setuid layer. 
This is not final, and I would like to see a paranoia() call or somesuch
for util_script.c. 

The User and Group directives have been extended to scope into the VHost
level...allowing you to define a User and Group for each VHost.  UserDirs
are handled automagically.

I'll finish up by giving you a quick tour of how suEXEC works...

1.  At startup (and at SIGHUP?), the server checks for the suexec binary,
as DEFINEd at compilation.  If it exists, is owned by root, and is
setuid'd, it enables suexec.  It any of these checks fail, it disables

2.  When call_exec is executed, it checks to see if suexec is enabled.  If
not, it will behave per Apache norm.  If so, then it continues...

3.  It checks to see if the User or Group defined for the host of the
current request is different from the User and Group defined for the main
server; *OR* if the request is within a ~userdir.  If not, it will behave
per Apache norm.  If so, then it continues... 

4.  If the request is within a UserDir, it modifies the call to the setuid
binary slightly.  If not it leaves the request alone.

5.  The setuid layer is executed.  The following checks are made, and
if any fail, the setuid layer spits out an error and returns:
	* correct number of arguments?
	* at hard limit for open files?
	* is uid of current user valid?
	* is the current user allowed to execute this code (i.e. is this
          the server?)
	* is there a '/' in the requested command?
Then, it checks to see if it is within a UserDir.  If so, it uses the
user's homedir as the DOC_ROOT.  If not, it uses the DEFINEd DOC_ROOT.
	* is the current working directory within the DOC_ROOT?
	* can we stat the current directory, and is it a directory?
	* is the current working dir not writable by others?
	* can we stat the target program, and is it not a link?
	* is the target program not writable by others?
	* is the target program not setuid or setgid?
	* is the target userid valid?
	* is the target groupid valid?
	* are the dir and file owner/group the same as target owner/group?
	* is the target uid not 0?
	* is the target gid not 0?
	* were initgroups() and setgid() properly executed?
	* was setuid() properly executed?

That's pretty much the current design and status.  I apologize if I was
unclear on any of's WAY to early.  8)

To close, here is what I see on the TODO list to finish this up.  Any
additions, deletions, code patches, et cetera are greatly appreciated.
	* paranoia() routine within server
	* Directory/Location User and Group implementation
	* better documentation
	* better logging, including logging exec errors to the target
	  user's homedir instead-of/as-well-as logging to the server.
	* allow limited root suEXEC behaviour somehow (MAYBE)

+ Jason A. Dour                            +
| Programmer Analyst II      |
| Dept. of Radiation Oncology         Finger for Geek Code, PGP Public Key,|
+ University of Louisville            PJ Harvey info, and other stuff...   +

Version: 2.6.2


View raw message