httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Barrett" <jbarr...@iplay.net>
Subject Re: Questions regarding viability of development plan
Date Mon, 18 Sep 2000 01:20:16 GMT
I've got the patches for apache 1.3.12 to pull off switching uid/gid per request, which I never
contributed after the reception that
this idea got the few times it has been suggested in the past.

there is a slight security hole in that perl can switch uid/gid back up to root, but I suspect
this can be blocked out at the perl
level if absolutly needed. It has never been an issue here as I write all the CGI, I just
needed to secure the customers webspaces
from other customers.

And actually, its not all that hard to patch, coupla changes to allow User/Group directives
without SUEXEC being detected, getting
rid of the complaint that apache is running as root, uid/gid changes immediatly once the virtual
server has been determined from the
request, and switching back to root at the end of the request.

I personally dont see any other viable solution, forcing ISPs to run everything as external
CGI to enforce a security model is just
a waste of cpu cycles, and using suexec still doesnt address the problem of having the customer
login own the directory/files for a
virtual server while still allowing apache to read the files (setting the files to a common
group isnt a solution, files might as
well be world readable if everyone with a web account can read all the scripts in other customers
directories, thereby exposing
database passwords, etc).

The only other solution would be true ACL support on *nix, but the most common flavors of
*nix dont have ACL support yet (or you
have to jump through hoops to get it, such as the ACL patches for Linux). Given ACLs, you
would then be able to give Apache access
to the webspace no matter who owned the files. (one problem here would be if scripts were
creating files, they would be owned by
apache, and not the customer, just another stumbling block that changing uid/gid doesnt run
into)

All the screaming about buffer overrun threats and root hacks from the dev team is understandable,
but it makes me wonder about
their confidence in the core request code. I seems to me it should be easy enough to make
sure that there are no holes in the basic
core. In any case, the changes could be wrapped up as a configuration option so that only
people that want this functionality get
it. Everyone else would see Apache "the way it is" :)

So I'll join with Lynn and all the other folks that have requested Per Virtual UID/GID support,
its an idea whose time has come !!!

John Barrett
Intersite Technologies
http://www.isitetech.com

----- Original Message -----
From: Lynn Winebarger <lynn@freespeech.org>
To: <new-httpd@apache.org>
Sent: Sunday, September 17, 2000 5:28 PM
Subject: Questions regarding viability of development plan


>
>    Sorry to butt into the list like this, but there wasn't a list faq or
> searchable archives for recent postings.
>    The non-profit free ISP I'm working for wants to expand its paying
> customer base, and I'd like to be able to offer scripting services (I just
> got them moved over to a Linux system from NT).  Unfortunately, Apache
> only supports a single UID per server configuration.  As far as I can
> tell, I have basically 4 options:
> 1) let them all run on the same server with the same UID, possibly munging
> everyone else's files (unacceptable)
> 2) run a bunch of different servers, one for each vhost with scripting,
> each using a different port (doable, but seems like it would waste
> considerable resources in terms of duplicating processes
> [unnecessarily]).
> 3) set up suexec (say goodbye to mod_php and/or mod_perl)
> 4) hack away at Apache to enable per virtual host user ids internally
> (requiring all process to either run as root with all attendant deadly
> hazards, or force processes to only deal with single vhost requests)
> [(5) Wait for Apache 2.0 to become stable?]
>
>    Given my inclination for tilting at windmills, (4) seems like the most
> desirable choice, with each process switching to the appropriate uid/gid
> for each request.  While I know this can't be easy (else it would have
> been done already), it would seem that the current constraint of having a
> single user id would make it possible to do at a high enough level in the
> request processing stage to be transparent (the idea being no request
> actually gets processed as the root user, some other UID/GID is always
> assumed before starting processing).
>     The other thing I need (to implement) is a mass virtual hosting system
> that determines capabilities for the virtual host nearly on the fly (or
> least can be updated within some reasonably bounded amount of time by
> staff without my direct intervention - I don't know how long I'll be
> working here, and they need a simple process for updating members'
> accounts).  Maybe someone could explain (or point me to an explanation) of
> why file descriptors are needed on a per-virtual host basis (with vhosts
> in the config file, at least).
>     I wouldn't be the only (or necessarily even main) person working on
> this.  At this point, I need to determine whether it's even a viable
> course of action, and where there be dragons if we do decide to pursue it.
> So, please, disabuse me of my misconceptions.
>
> Lynn
>
>
>
>


Mime
View raw message