httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Harris" <dhar...@drh.net>
Subject RE: better suexec control proposal
Date Wed, 16 Feb 2000 16:55:37 GMT

I've thoroughly hacked up suexec to meet my needs. Here's a quick summary of
what I did, in case it is useful to someone else:

(1) Added an on/off feature for suexec on a per-webserver basis, so I can use
one binary build for multiple server instances, some of which need suexec and
some of which don't.

(2) Added an disable/enable option for suexec on a per-virtual-host basis. I
wanted to be able to forbid some of my customers from using suexec, if needed.

(3) Modified suexec so that it no longer read the user and group from the User
and Group configuration directives. It now reads the user to switch to from the
owner of the file it is about to execute (with appropriate restrictions) IF the
file ends in the "-set" extension. Without the "-set" extension, the program is
run as nobody.  This allows me to setup the ".cgi" extension to run normally
and the ".cgi-set" extension to privileged.

Since there are no User and Group directives you can have multiple users in one
virtual host without per-directory configuration. A simple rewrite rule allows
a user to rename a cgi from ".cgi" to ".cgi-set" and still call it using the
".cgi" name, so adding privilege to a script is easy. I also like this better
than setuid, because it's obvious that a script is privileged (in the name, not
in the mode) and the privilege is not removed whenever the script is edited, as
with the setuid bit.

I think this is a nice way to handle the whole suexec problem, but I doubt that
a change this far reaching would be accepted.

 - David Harris
   Principal Engineer, DRH Internet Services



Mime
View raw message