httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: Anywhere to go for a summmary of I/O filtering?
Date Mon, 24 Jul 2000 18:16:15 GMT
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Monday, July 24, 2000 12:44 PM
> 
> > > per process User/Group assignment
> > 
> > Does anyone have the description here?  And do unix threads allow
> > thread-based user/group impersonation?  It seems like we may have
> > another MPM split here, win32 does thread/user impersonation, and
> > other platforms may require proc/user impersonation.
> 
> I should have an new MPM to implement this some time in the next few
> weeks.  I have a lot of projects that I am working on right now, for
> Apache and for Covalent and myself.  Basically, all we need to do, is
> re-write Dexter to have a specified user per process.  When a child
> process gets a request that is destined for another virtual host, it looks
> that up in a shared table, and forwards off the request and socket.  The
> threads themselves do not change ownership at all, the server just
> redirects the requests to the right process.

Then we simply have VHostAsUser joe and VHostAsGroup webauthors
properties going?  What about passwords, I assume the issue is 
mute under unix?  And I'm assuming we aren't discussing running
as the client/user, only the author.

And are we certain that the virtualhost is sufficient?  I'm picturing, as
a commerce administrator, that I have a group of administration scripts
in a common share-bin folder that all should run as user isp_common,
while their folders can all use their own id's.  The individual web admins
have no permissions to the common cgi (they can't hack them), while they
still have cgi-bin to play their own games.

> I have no clue how to implement this sort of thing on 
> Windows, so I am not even going to try.

Don't worry about it :)  I'm picturing toggling the ImpersonateLoggedOnUser
for the given thread, and RevertToSelf at the end of the request.  Logged
on users and tokens can be cached, so the hit should be nominal.  If we
structure it right, it should be fluid between Unix and Win32, although
implemented quite differently.

> NO!  Async is a huge change.  It is not going to go into 2.0, because it
> will require a complete re-write.  I really think we need to learn a bit
> about filtering in 2.0, and apply that knowledge to a 3.0 async server.

That's fine.  Forewarn and forearm module authors that filtering is subject
to overhaul when async is implemented in 3.0 ...

What 3.0 major feature did you have in mind when you suggested that async 
is a feature for 4.0?

I have only two concerns:

  1) async may become a major consideration for authors/administrators when
     it comes to choosing their web server in 2002, if it's not already.

  2) async may blow our filters design out of the water if we don't bear it
     some consideration (not _implementation_, only _design_) as we create
     the filter api.  I don't want to give the authors in 2002 the choice
     between rewriting their module for Apache and rewriting for another
     platform.  If we bear it in mind, we can avoid big rewrites (unless
     they want to fully exploit async, which is a different issue.)

If we design async, and then stub it for filters, we can keep moving and 
no code will be harmed in the production.  When we are ready to expose it,
then we can revamp the server.  As it is, I'm reviewing mod_isapi to fully
implement the API, but emulate async for authors so they aren't coding 
twice, and for admins who aren't interested in arguing with the coder.

Bill

Mime
View raw message