You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Lynn Winebarger <ly...@freespeech.org> on 2000/09/18 00:28:37 UTC
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
Re: Questions regarding viability of development plan
Posted by "Victor J. Orlikowski" <v....@gte.net>.
Doh. Mail to wife. Please excuse....
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
vjo@raleigh.ibm.com
vjo@us.ibm.com
Re: Questions regarding viability of development plan
Posted by "Victor J. Orlikowski" <v....@gte.net>.
Too late. Already took the coins to the bank. I looked all around, but
I can't find a fourth roll *anywhere*. I guess you counted
wrong. Still, the 83.50 on your desk isn't bad :)
And if we find the other, I'll take it to Food Lion.
Feeling some better....
Love you,
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
vjo@raleigh.ibm.com
vjo@us.ibm.com
Re: Questions regarding viability of development plan
Posted by Lynn Winebarger <ly...@freespeech.org>.
On Mon, 18 Sep 2000 rbb@covalent.net wrote:
> On Mon, 18 Sep 2000, Greg Ames wrote:
> > Lynn Winebarger wrote:
> > > 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?]
> > >
> >
> > Ryan, what about your perchild mpm? Would that help here?
>
> That's option #5, wait for 2.0.
>
But the question is, which do you think will take longer; 2.0 to
become stable (and the mod_* interpreters to be ready for it, and
efficient enough to be useable), or to do 4 and a security audit
(including at least the more popular modules).
John Barret's comment leads me to think (a) I'm not the only one
wanting this feature/highly probably security hole, and (b) it's been
discussed before. Maybe someone can point me to when one of those
discussions took place so I can look it up for the
(non-obvious/apache-specific) issues involved?
Lynn
Re: Questions regarding viability of development plan
Posted by rb...@covalent.net.
On Mon, 18 Sep 2000, Greg Ames wrote:
> Lynn Winebarger wrote:
> >
> [...]
> > 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?]
> >
>
> Ryan, what about your perchild mpm? Would that help here?
That's option #5, wait for 2.0.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Questions regarding viability of development plan
Posted by Greg Ames <gr...@raleigh.ibm.com>.
Lynn Winebarger wrote:
>
[...]
> 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?]
>
Ryan, what about your perchild mpm? Would that help here?
Greg
Re: Questions regarding viability of development plan
Posted by James Sutherland <ja...@cam.ac.uk>.
On Sun, 17 Sep 2000, John Barrett wrote:
> 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.
You are changing EUID, I take it, but not RUID, meaning a Perl script
could just do a $> = $< and be back as root? Just setting EUID==RUID
before any exec calls should plug that hole, surely??
> 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.
Not too hard; IMO, it should go in, or at least be better publicised :-)
> 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).
Agreed. Having per-vhost UIDs is a big plus in some environments...
> 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)
Hrmm... nah. That doesn't solve very much, really. The main issue is with
scripting; if you want a file to be private, don't put it in a ... WWW
document root!!
> 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" :)
This shouldn't introduce new any security issues - it should be equivalent
to simply running one server per vhost, each running with a different UID,
only more efficient.
> 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 !!!
Agreed - particularly if there's a decent security audit beforehand...
James.
Re: Questions regarding viability of development plan
Posted by John Barrett <jb...@iplay.net>.
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 <ly...@freespeech.org>
To: <ne...@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
>
>
>
>