httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Harris" <dhar...@drh.net>
Subject Fork off a more feature full suexec?
Date Fri, 12 Mar 1999 02:52:01 GMT
Hi,

Gary Shea wrote:
> This is true, but at the risk of being an effete aesthete, I must
> say, it's a hell of an ugly way to accomplish the job!  Effective,
> yes... satisfying... no.
>
> Hopefully I don't have to settle for CGIwrap ;)

I am writing my own suexec-like thingy to execute scripts as the user who
owns them with the specific intent of replacing cgiwrap in my system setup.
Basically taking suexec into the scary netherlands where more functionality
exists.

Advantages of my suexec-thingy over cgiwrap and/or suexec-standard:

(1) Nice clean solution to the problem.

(2) Reads the user from the file to be executed. This means no more
one-user-per-VirtualHost restriction. To be more specific: programs whose
name ends in "-set" are run as the owner of the file, while other programs
are run as nobody. One could say this creates an "artificial setuid" by
ending the program name in "-set".

(3) Works with CGI mod_actions triggered interpreters such as php/fi - the
shared interpreter CGI gets run as the user from the file it will execute.
This requires a simple patch to mod_actions, to create a REDIRECT_FILENAME
environment variable, and some strict checking of the environment passed to
the approved CGI interpreter.

(4) CGI debugging information over and above what cigwrap offers. This
consists of spiting out the appropriate header, showing the form information
(get and post) along with the environment, then duping STDOUT over STDERR
and running the script. All this mess will actually be done by another
program exec'ed by suexec.

I am highly interested in sharing this work with the community, and perhaps
developing it with a few people. This kind of programming is best worked on
and reviewed by more than one set of eyes.

I fully understand why the core wants to keep the current suexec code as
simple as possible. That's why I think this needs to be broken off as a
separate little development effort. The source of this suexec-thingy would
not even be distributed in the Apache tarball - it would be as separate and
apart as possible.

Anyone interested?

 - David Harris
   Principal Engineer, DRH Internet Services


-----Original Message-----
From:	new-httpd-owner@apache.org [mailto:new-httpd-owner@apache.org] On
Behalf Of Gary Shea
Sent:	Thursday, March 11, 1999 9:30 PM
To:	new-httpd@apache.org
Subject:	Re: suexec: lstat vs stat

On Thu, 11 Mar 1999, Jim Jagielski wrote:
> Gary Shea wrote:
> >
> > I'd really love to see some willingness on the part of the Apache folks
> > to entertain an option where a FULLY external suexec-y thing could be
> > hooked up to Apache.  I'd prefer to take over ALL decisions about what
> > user runs the cgi/ssi based entirely on the file requested.  Once an
> > API of this sort is defined, I won't have to rewrite my patches every
> > month or two...
> >
>
> In some way, CGIwrap already does some of that, but it's API is simply
> CGI :) It's main basic mode of operation is to look at the owner
> and location of a script and then run as that user.
>
> --
>
===========================================================================
>    Jim Jagielski   |||   jim@jaguNET.com   |||   http://www.jaguNET.com/
>             "That's no ordinary rabbit... that's the most foul,
>             cruel and bad-tempered rodent you ever laid eyes on"

This is true, but at the risk of being an effete aesthete, I must
say, it's a hell of an ugly way to accomplish the job!  Effective,
yes... satisfying... no.

Hopefully I don't have to settle for CGIwrap ;)

	Gary

-----------------------------------------------------------------
Gary Shea                                       shea@xmission.com
Salt Lake City                      http://www.xmission.com/~shea


Mime
View raw message