You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Steinar H. Gunderson" <sg...@bigfoot.com> on 2007/06/17 21:47:33 UTC
Inclusion of mpm-itk into HEAD
[Please Cc me on any replies, I'm not subscribed to the list]
Hi,
I'd like to request the inclusion of the ITK MPM (mpm-itk) as an official MPM
in the Apache tree, for Apache 2.4/3.0. mpm-itk is basically a modified
prefork allowing each vhost to run as a different uid/gid, ie. sort of like
what perchild was supposed to do. The biggest differences between mpm-itk and
perchild/Metux/peruser are:
- mpm-itk is in production use at several sites -- for instance, most sites
under .ntnu.no generally use mpm-itk, totaling about nine million hits a
day. Even though it is still under experimental/ in the tree, most real
issues have long since been ironed out -- it is not a proof-of-concept,
but a real, working tool. It works flawlessly with SSL and most
third-party modules (mod_ruby being a notable exception).
- mpm-itk is not threaded, which means you can run the full range of evil
third-party modules (such as PHP and its extensions) without problems.
- mpm-itk does not require any sort of special kernel modules or
configuration. It should generally work on the same platforms as prefork
does, given that it's a direct prefork descendent. It's a pluggable
replacement for prefork; most sites wouldn't really notice the difference
if you took out prefork and replaced it with mpm-itk, until you start
actually using AssignUserID. This provides a smooth migration path.
Two main disadvantages should be noted:
- setuid() happens after the request has been parsed, which means that the
server runs as root up until that point. (However, on a system with
capabilities, ie. Linux 2.6, almost all superuser privileges are dropped,
so you can't just load kernel code or whatever.)
- There is a performance drop from prefork, as each child is only serving
one connection before it dies -- I haven't done any detailed benchmarking
on this, but my general impression is: If you're serving static content
and you're strained for performance, it matters. If you're serving dynamic
content or large static files, it probably just disappears in the equation.
Despite these disadvantages, I believe it would be a useful addition to the
upstream tree -- these are largely results of design decisions in order to
keep the design as close to prefork as possible, instead of designing a new
grand scheme that will take a lot of time to get right. mpm-itk is included
in at least Debian, Ubuntu, Gentoo, and in FreeBSD ports, and based on the
numbers from Debian's popularity contest (which is not a statistically valid
sample, but nevertheless a good indication) is the third most popular MPM
(after prefork and worker, but clearly ahead of event).
The full set of patches, against Apache 2.2.3, is available from
http://home.samfundet.no/~sesse/mpm-itk/apache2.2-mpm-itk-2.2.3-04/
I'll of course be happy to update these to apply against HEAD if needed,
transfer copyright to the ASF, and write any needed documentation. However,
given that the "runs as root" issue has proved somewhat controversial
earlier, I don't think it's appropriate to do that kind of upstream
integration work before some kind of decision has been made :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: Inclusion of mpm-itk into HEAD
Posted by Paul Querna <ch...@force-elite.com>.
Joshua Slive wrote:
> On 6/25/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>> That said, have you considered a design where there are separate pools
>> of processes per-user, and these would be dispatched after the headers
>> are processed to the appropriate child?
>
> The simplest option is to simply reuse the features that already exist
> to get that effect:
> http://wiki.apache.org/httpd/Recipes/Different_UserIDs_Using_Reverse_Proxy
>
> It's never going to be as fast as perchild, since it uses
> "inefficient" http for the dispatching. But it will beat the pants off
> of an mpm that serves only one connection per process at the expense
> of slightly more memory.
>
> It would be nice if that could be accomplished with a single instance
> of httpd and a single config file. Implementing that would probably be
> simpler than solving the perchild problems.
+1, I also believe that an automated proxy + child running as that user
is the best way to go. It would be a complete code-reuse for all of the
proxying, and avoid the issues found with most other approaches.
The hardest part, is making it easy to configure. I imagine the best
way is to introduce a new VirtualHost block replacement, which the
module would internally rewrite to a basic vhost block with a proxypass
for the master, and a separate vhost block for the child, running as the
specified user.
-Pual
Re: Inclusion of mpm-itk into HEAD
Posted by Joshua Slive <jo...@slive.ca>.
On 6/25/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> That said, have you considered a design where there are separate pools
> of processes per-user, and these would be dispatched after the headers
> are processed to the appropriate child?
The simplest option is to simply reuse the features that already exist
to get that effect:
http://wiki.apache.org/httpd/Recipes/Different_UserIDs_Using_Reverse_Proxy
It's never going to be as fast as perchild, since it uses
"inefficient" http for the dispatching. But it will beat the pants off
of an mpm that serves only one connection per process at the expense
of slightly more memory.
It would be nice if that could be accomplished with a single instance
of httpd and a single config file. Implementing that would probably be
simpler than solving the perchild problems.
Joshua.
Re: Inclusion of mpm-itk into HEAD
Posted by "Steinar H. Gunderson" <sg...@bigfoot.com>.
On Mon, Jun 25, 2007 at 11:06:11AM -0500, William A. Rowe, Jr. wrote:
> That said, have you considered a design where there are separate pools
> of processes per-user, and these would be dispatched after the headers
> are processed to the appropriate child?
Yes, I have considered it briefly, and it's just beyond my reach. The biggest
problem seems simply to be dispatching all the state; it seems like all
modules running pre-parse would need to be able to serialize/deserialize
state, or optionally split parts of the modules out into separate helper
daemons. This seems to be rather difficult, which is probably part of the
reason why perchild never took off.
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: Inclusion of mpm-itk into HEAD
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
> "Steinar H. Gunderson" <sg...@bigfoot.com> wrote:
>
>> - setuid() happens after the request has been parsed, which means
>> that the server runs as root up until that point. (However, on a
>> system with capabilities, ie. Linux 2.6, almost all superuser
>> privileges are dropped, so you can't just load kernel code or
>> whatever.)
>
> First there's the obvious issue of any bugs in the core code
> (which includes yours - if it goes in) going nuclear by running
> as root.
>
> But secondly, it does the same for a lot of module code. Any
> module that runs a connection-level input filter, such as SSL,
> a protocol module, or a bandwidth-shaping module, is going to
> have code run as root. That means a lot of existing third-party
> code goes nuclear too. Including it in the core dist makes a
> huge target! People get pwned, apache gets the blame.
This has been a design constraint from the very early days, which is why
I expect your MPM would not be included in the core distribution. We
have a very similar issue (to be solved differently) in mod_ftp, when the
user insists that the data port must be bound to a low #'ed (traditional)
ftp data port. Defining a block of high numbered ports through the router
is the suggested way to go.
That said, have you considered a design where there are separate pools
of processes per-user, and these would be dispatched after the headers
are processed to the appropriate child?
Of course, this brings us back to perchild which has been longing for
some time for more attention. But that said - your module does offer
something to compliment perchild for users of thread-unsafe module
designs, and provides the process separation that some admins desire.
Bill
Re: Inclusion of mpm-itk into HEAD
Posted by "Steinar H. Gunderson" <sg...@bigfoot.com>.
On Mon, Jun 25, 2007 at 12:13:31PM -0700, Sander Temme wrote:
> How would that work for multiple requests on keptalive connections?
> Wouldn't that allow me to send a sequence like
>
> GET /yourpage HTTP/1.1
> Host: yourhost.com
> Connection: Keep-Alive
> ...
>
> which would be dispatched to run as you, followed
>
> GET /badasshackscript HTTP/1.1
> Host: theotherguy.com
> ...
>
> over the same connection, which would have badasshackscript be found
> on the other guy's vhost but executed as you?
In that case, mpm-itk simulates a timeout and simply closes the TCP
connection (which makes the browser reconnect). Works well in practice, and
is AFAICS allowed by RFC 2616.
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: Inclusion of mpm-itk into HEAD
Posted by Sander Temme <sc...@apache.org>.
On Jun 25, 2007, at 3:04 AM, Steinar H. Gunderson wrote:
>> So you've introduced something that looks much the same as the
>> traditional "CGI overhead", but applied it to every request instead
>> of just CGI?
>
> Every single _connection_, but yes.
How would that work for multiple requests on keptalive connections?
Wouldn't that allow me to send a sequence like
GET /yourpage HTTP/1.1
Host: yourhost.com
Connection: Keep-Alive
...
which would be dispatched to run as you, followed
GET /badasshackscript HTTP/1.1
Host: theotherguy.com
...
over the same connection, which would have badasshackscript be found
on the other guy's vhost but executed as you?
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Inclusion of mpm-itk into HEAD
Posted by "Steinar H. Gunderson" <sg...@bigfoot.com>.
On Mon, Jun 25, 2007 at 09:20:45AM +0100, Nick Kew wrote:
>> - mpm-itk is in production use at several sites -- for instance,
> Isn't that also true of metux?
I don't know. Can you point me to any sites? Does Metux even support SSL yet?
> That looks like a serious problem to me.
>
> First there's the obvious issue of any bugs in the core code
> (which includes yours - if it goes in) going nuclear by running
> as root.
>
> But secondly, it does the same for a lot of module code. Any
> module that runs a connection-level input filter, such as SSL,
> a protocol module, or a bandwidth-shaping module, is going to
> have code run as root. That means a lot of existing third-party
> code goes nuclear too. Including it in the core dist makes a
> huge target! People get pwned, apache gets the blame.
> For example, it looks a lot like a case of
> itk + slapper = remote root
Well, there's a tradeoff here. First of all, note that mpm-itk runs with a
very limited set of root capabilities on platforms (ie. Linux 2.6) where this
is possible; you cannot, for instance load new kernel code, you'd have to
setuid to a different user and hope that that user has enough privileges to
spoof yourself back into root directly or indirectly somehow. Second, you need
to balance this potential issue against the issue the code solves in the
first place (as mentioned in my other e-mail, the fact that different vhosts
have full read access to each others' files).
Given that the potential damage is large but risk is relatively low (when did
Apache core last have an remote-exploitable bug like this?), and the problem
we're protecting against has a medium damage and happens every day, I think the
admin should ultimately be the one to decide whether this is a good tradeoff
or not. We should of course be very clear on what the advantages and
disadvantages are, but IMNSHO (being the author :-) ) the choice should be
there.
> So you've introduced something that looks much the same as the
> traditional "CGI overhead", but applied it to every request instead
> of just CGI?
Every single _connection_, but yes.
> How does it offer any advantage over CGI+suexec?
> Not to mention its variants like fastcgi?
It works with PHP (without having to run PHP as CGI, which has its own
different sets of kludges). It works with mod_perl applications. It works
with mod_dav_svn. It handles static files exactly the same as it handles
dynamic files. It is extremely simple to set up, and rather difficult to set
up wrong.
By the way, I seem to have forgotten in my last post to mention that mpm-itk
is also in Mandriva Linux. Sorry for leaving you out :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: Inclusion of mpm-itk into HEAD
Posted by Nick Kew <ni...@webthing.com>.
On Sun, 17 Jun 2007 21:47:33 +0200
"Steinar H. Gunderson" <sg...@bigfoot.com> wrote:
> - mpm-itk is in production use at several sites -- for instance,
Isn't that also true of metux?
> Two main disadvantages should be noted:
Thanks for being clear about these up-front.
> - setuid() happens after the request has been parsed, which means
> that the server runs as root up until that point. (However, on a
> system with capabilities, ie. Linux 2.6, almost all superuser
> privileges are dropped, so you can't just load kernel code or
> whatever.)
That looks like a serious problem to me.
First there's the obvious issue of any bugs in the core code
(which includes yours - if it goes in) going nuclear by running
as root.
But secondly, it does the same for a lot of module code. Any
module that runs a connection-level input filter, such as SSL,
a protocol module, or a bandwidth-shaping module, is going to
have code run as root. That means a lot of existing third-party
code goes nuclear too. Including it in the core dist makes a
huge target! People get pwned, apache gets the blame.
For example, it looks a lot like a case of
itk + slapper = remote root
> - There is a performance drop from prefork, as each child is only
> serving one connection before it dies
So you've introduced something that looks much the same as the
traditional "CGI overhead", but applied it to every request instead
of just CGI? How does it offer any advantage over CGI+suexec?
Not to mention its variants like fastcgi?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Inclusion of mpm-itk into HEAD
Posted by Graham Dumpleton <gr...@gmail.com>.
On 25/06/07, Steinar H. Gunderson <sg...@bigfoot.com> wrote:
> On Mon, Jun 25, 2007 at 08:47:03PM +1000, Graham Dumpleton wrote:
> >> Yes, it is obviously an alternative, but FastCGI has its own sets of
> >> quirks, and PHP under CGI too (as far as I know; I'm no PHP user).
> > Quirks such as? Am not asking to dispute that there aren't any, just
> > asking out of ignorance as to what they are so I can learn something.
>
> I haven't been particularly involved with it at the local installation here,
> but I've seen problems with FastCGI stuff hanging, not dealing well with
> scripts leaking memory, and being difficult to set up. In general, it didn't
> make people happy. (It may make other people very happy; people differ.)
And I have heard those complaints as well, but all that means is that
the implementation has problems not the actual concept of how it
works. :-)
Graham
Re: Inclusion of mpm-itk into HEAD
Posted by "Steinar H. Gunderson" <sg...@bigfoot.com>.
On Mon, Jun 25, 2007 at 08:47:03PM +1000, Graham Dumpleton wrote:
>> Yes, it is obviously an alternative, but FastCGI has its own sets of
>> quirks, and PHP under CGI too (as far as I know; I'm no PHP user).
> Quirks such as? Am not asking to dispute that there aren't any, just
> asking out of ignorance as to what they are so I can learn something.
I haven't been particularly involved with it at the local installation here,
but I've seen problems with FastCGI stuff hanging, not dealing well with
scripts leaking memory, and being difficult to set up. In general, it didn't
make people happy. (It may make other people very happy; people differ.)
> And I think you will have similar problems with mod_perl as well given
> that it relies to a degree on preloading and caching of Perl modules
> as well.
It depends on your application. If you're using Apache::Registry to just
accelerate your CGI-like scripts, it won't help much. OTOH, you can easily
preload Perl modules using PerlModule directives, which will then be
available and loaded before the fork. Of course, this could also include your
entire application if it's not Apache::Registry; we do this in production.
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: Inclusion of mpm-itk into HEAD
Posted by Graham Dumpleton <gr...@gmail.com>.
On 25/06/07, Steinar H. Gunderson <sg...@bigfoot.com> wrote:
> On Mon, Jun 25, 2007 at 08:08:03PM +1000, Graham Dumpleton wrote:
> > Or you can use PHP under fastcgi. With fastcgi the code would run in a
> > separate process and you could have any number of processes
> > corresponding to whatever virtual hosts you have. Because it is a
> > separate process it can run from the outset as whatever user you want
> > thus avoiding any danger points where code would be run as root.
>
> Yes, it is obviously an alternative, but FastCGI has its own sets of quirks,
> and PHP under CGI too (as far as I know; I'm no PHP user).
Quirks such as? Am not asking to dispute that there aren't any, just
asking out of ignorance as to what they are so I can learn something.
> Also, it won't
> help you for anything that runs as a module; say, mod_dav_svn or mod_perl.
>
> Various solutions to this problem have different tradeoffs -- among them
> performance, security, complexity and applicability to different scenarios.
> What mpm-itk gives you is a very simple solution that's one line per vhost
> and works with a _lot_ of different use cases out of the box; I believe that
> has a value in itself. Of course, I'd very much prefer a "real" perchild that
> setuids before accepting the connection and then does connection passing, but
> we're now several years (and at least SoC project) since the release of
> Apache 2.0, and it doesn't really seem to be appearing anytime soon.
>
> >> Doesn't mod_python load these up-front, so they'd be available before the
> >> fork?
> > No. The only thing which is done before the fork is the initialisation
> > of the Python interpreter. It isn't safe to do anything more than that
> > as the parent process runs as root.
>
> OK, then performance will suffer in this scenario.
And I think you will have similar problems with mod_perl as well given
that it relies to a degree on preloading and caching of Perl modules
as well.
BTW, for a different take on this whole problem you might have a look
at mod_wsgi (www.modwsgi.org). This only solves the problem for a
specific language, but it provides the choice of running a Python web
application embedded in the Apache child process (like mod_python), or
delegated to a daemon process (like mod_fastcgi). The mod_wsgi code
takes concepts such as process management from mod_cgid and proxying
of requests to the daemon process from mod_cgid and mod_scgi. Where it
is different to solutions like mod_scgi and mod_fastcgi though is that
the daemon process is a fork of the parent process, not a distinct
exec'd process. The daemon process then uses Apache/APR to construct
just enough of the normal Apache connection processing code to fake up
a request_rec and bucket chain, that way the exact same handler code
as would be used in the Apache child can be used.
Graham
Re: Inclusion of mpm-itk into HEAD
Posted by "Steinar H. Gunderson" <sg...@bigfoot.com>.
On Mon, Jun 25, 2007 at 08:08:03PM +1000, Graham Dumpleton wrote:
> Or you can use PHP under fastcgi. With fastcgi the code would run in a
> separate process and you could have any number of processes
> corresponding to whatever virtual hosts you have. Because it is a
> separate process it can run from the outset as whatever user you want
> thus avoiding any danger points where code would be run as root.
Yes, it is obviously an alternative, but FastCGI has its own sets of quirks,
and PHP under CGI too (as far as I know; I'm no PHP user). Also, it won't
help you for anything that runs as a module; say, mod_dav_svn or mod_perl.
Various solutions to this problem have different tradeoffs -- among them
performance, security, complexity and applicability to different scenarios.
What mpm-itk gives you is a very simple solution that's one line per vhost
and works with a _lot_ of different use cases out of the box; I believe that
has a value in itself. Of course, I'd very much prefer a "real" perchild that
setuids before accepting the connection and then does connection passing, but
we're now several years (and at least SoC project) since the release of
Apache 2.0, and it doesn't really seem to be appearing anytime soon.
>> Doesn't mod_python load these up-front, so they'd be available before the
>> fork?
> No. The only thing which is done before the fork is the initialisation
> of the Python interpreter. It isn't safe to do anything more than that
> as the parent process runs as root.
OK, then performance will suffer in this scenario.
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: Inclusion of mpm-itk into HEAD
Posted by Graham Dumpleton <gr...@gmail.com>.
On 25/06/07, Steinar H. Gunderson <sg...@bigfoot.com> wrote:
> On Mon, Jun 25, 2007 at 02:36:41PM +1000, Graham Dumpleton wrote:
> > What specific applications are you running that require things to be
> > run as a distinct user? Are these applications implemented directly in
> > C as custom Apache modules, or are you writing stuff in other
> > languages, ie., such as PHP, Perl, running under mod_php or mod_perl?
> > What are the perceived reasons that solutions such as mod_fastcgi,
> > mod_scgi or the various mod_proxy type solutions wouldn't be a viable
> > alternative for hosting your application?
>
> The main point is separating the vhosts better from each other. Think of your
> typical PHP application, doing something along the lines of
>
> /srv/vhost1/database.php:
> $conn = pg_connect("blablabla", "username", "mysupersecretpassword");
>
> Now, since database.php must be readable by www-data, a different user on the
> same server could write something along the lines of:
>
> /srv/vhost2/evil.php:
> passthru("cat /srv/vhost1/database.php");
>
> and get the password.
>
> There are various ways of trying to taper over this in the programming
> language (such as PHP), but they all have their disadvantages, and they don't
> apply to other languages, .htaccess/.htpasswd files, static files, etc.. This
> is the specific scenario that mpm-itk is designed to resolve, and it seems to
> be a very real problem in a rather large number of real installations.
Or you can use PHP under fastcgi. With fastcgi the code would run in a
separate process and you could have any number of processes
corresponding to whatever virtual hosts you have. Because it is a
separate process it can run from the outset as whatever user you want
thus avoiding any danger points where code would be run as root.
> > For mod_python based Python applications such as Django and
> > TurboGears, which have a memory footprint starting at about 7MB and
> > 15MB respectively, any performance loss would not 'just disappear in
> > the equation" as the load time for each request would be significant
> > given that process would be thrown away after each request and
> > everything would need to be reloaded.
>
> Doesn't mod_python load these up-front, so they'd be available before the
> fork?
No. The only thing which is done before the fork is the initialisation
of the Python interpreter. It isn't safe to do anything more than that
as the parent process runs as root.
Graham
Re: Inclusion of mpm-itk into HEAD
Posted by "Steinar H. Gunderson" <sg...@bigfoot.com>.
On Mon, Jun 25, 2007 at 02:36:41PM +1000, Graham Dumpleton wrote:
> What specific applications are you running that require things to be
> run as a distinct user? Are these applications implemented directly in
> C as custom Apache modules, or are you writing stuff in other
> languages, ie., such as PHP, Perl, running under mod_php or mod_perl?
> What are the perceived reasons that solutions such as mod_fastcgi,
> mod_scgi or the various mod_proxy type solutions wouldn't be a viable
> alternative for hosting your application?
The main point is separating the vhosts better from each other. Think of your
typical PHP application, doing something along the lines of
/srv/vhost1/database.php:
$conn = pg_connect("blablabla", "username", "mysupersecretpassword");
Now, since database.php must be readable by www-data, a different user on the
same server could write something along the lines of:
/srv/vhost2/evil.php:
passthru("cat /srv/vhost1/database.php");
and get the password.
There are various ways of trying to taper over this in the programming
language (such as PHP), but they all have their disadvantages, and they don't
apply to other languages, .htaccess/.htpasswd files, static files, etc.. This
is the specific scenario that mpm-itk is designed to resolve, and it seems to
be a very real problem in a rather large number of real installations.
> Known not to work with current versions of mod_python. This is because
> mod_python uses process mutexes for session locking between processes
> and the changing uid of the processes causes problems with this.
> Possible solutions have been discussed in:
>
> https://issues.apache.org/jira/browse/MODPYTHON-202
Yes, sorry, I forgot that part. For the record, it also has issues with
mod_ruby.
> For mod_python based Python applications such as Django and
> TurboGears, which have a memory footprint starting at about 7MB and
> 15MB respectively, any performance loss would not 'just disappear in
> the equation" as the load time for each request would be significant
> given that process would be thrown away after each request and
> everything would need to be reloaded.
Doesn't mod_python load these up-front, so they'd be available before the
fork?
/* Steinar */
--
Homepage: http://www.sesse.net/
Re: Inclusion of mpm-itk into HEAD
Posted by Rici Lake <ri...@ricilake.net>.
On 27-Jun-07, at 6:07 PM, Joshua Slive wrote:
> Good point. I moved some of this discussion into its own section,
> since it applies equally to the main example.
Yes, that's much better.
>
> I also removed your comments about needing separate LockFile/etc
> locations, since its not true in recent versions. (These files are
> created with the pid of the parent process appended to ensure they are
> unique.)
I actually tested that config file, and one of the stupid mistakes
I made was not putting a PidFile directive into each config. As
far as I can see, the ScoreBoardFile also needs a unique name;
only the lock file has the pid appended. Also, I had to manually
set UseCanonicalName Off, even though the manual says that's the
2.2 default. (This is a 2.2.4 installation from the FreeBSD port,
although I didn't set up a jailed test.)
In any event, if you're not starting the user servers as root,
which seems like the most secure setup, then it's quite possible
that they will not have write access to the /var subdirectories.
If they were started in a (chroot) jail then none of that would
be an issue.
The other issues I ran into were fairly minor: I had to map the
various modules and the mime.types file into places where the
user servers could see them.
I personally think this is quite a practical solution for
mass virtual hosting, but it would take a bit more work to
document and test.
It might well be useful to have a sort of "kiosk" version of
apache httpd, in which particular settings (for example, the
listening interfaces and some of the mpm tuning directives)
were locked down in some fashion. (Not everyone is going to
want to use FreeBSD jails.) The goal would be to allow the
user to directly write their own httpd configuration, thus
avoiding the need to use .htaccess files.
Re: Inclusion of mpm-itk into HEAD
Posted by Joshua Slive <jo...@slive.ca>.
On 6/27/07, Rici Lake <ri...@ricilake.net> wrote:
> If the user servers are listening on high ports, then they can be
> started as the user/group rather than as root, and the owner could
> have quite a bit of flexibility in configuring their server. It's
> quite possible that less reliance on .htaccess files would actually
> compensate for the additional cost of running multiple server
> instances.
Good point. I moved some of this discussion into its own section,
since it applies equally to the main example.
I also removed your comments about needing separate LockFile/etc
locations, since its not true in recent versions. (These files are
created with the pid of the parent process appended to ensure they are
unique.)
Joshua.
Re: Inclusion of mpm-itk into HEAD
Posted by Rici Lake <ri...@ricilake.net>.
On 27-Jun-07, at 1:01 PM, Joshua Slive wrote:
> On 6/27/07, Nick Kew <ni...@webthing.com> wrote:
>
>> This is a problem that could be solved by documentation.
>> Maybe not quite as simple, but when the alternative is accepting
>> new connections whilst running as root.
>
> Here's a start:
> http://wiki.apache.org/httpd/Recipes/Privilege_Separation
>
I just added a section to:
http://wiki.apache.org/httpd/Recipes/
Different_UserIDs_Using_Reverse_Proxy
which could also use a bit of polishing. It uses mod_rewrite to do the
proxying, rather than virtual hosts, which makes it possible to avoid
having to change the proxy server's configuration when adding or
deleting user servers.
If the user servers are listening on high ports, then they can be
started as the user/group rather than as root, and the owner could
have quite a bit of flexibility in configuring their server. It's
quite possible that less reliance on .htaccess files would actually
compensate for the additional cost of running multiple server
instances.
Re: Inclusion of mpm-itk into HEAD
Posted by Joshua Slive <jo...@slive.ca>.
On 6/27/07, Nick Kew <ni...@webthing.com> wrote:
> This is a problem that could be solved by documentation.
> Maybe not quite as simple, but when the alternative is accepting
> new connections whilst running as root.
Here's a start:
http://wiki.apache.org/httpd/Recipes/Privilege_Separation
It could use lots of polishing.
Joshua.
Re: Inclusion of mpm-itk into HEAD
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 27 Jun 2007 09:59:27 -0400
Rich Bowen <rb...@rcbowen.com> wrote:
> It's a request that comes up every single day in the various support
> forums: I am in a hosted environment, I have a virtual host, and a
> bunch of random strangers have full read permissions to my sensitive
> files, is there any way around this? So one of the main problems is
> not applications at all, but is static files. Folks want their
> static files to be owned by themselves, and not readable to random
> other users on the same system, but also serve-able by Apache.
Group permissions.
> There
> are various user and group permission that can make this
> sort-of-but-not- quite happen, because whatever you do, someone can
> write a cgi program that can read your files.
suexec.
> So, in that situation, mod_fastcgi, mod_scgi, or whatever, are
> completely ineffectual. Having a solution where FILES are read by
> some other UID would solve this long-standing complaint.
>
> Speaking only as help-desk personnel, and not as a code developer -
> I have no insight into how this would be implemented, I only answer
> the question, every day of every week for the last half-dozen years.
This is a problem that could be solved by documentation.
Maybe not quite as simple, but when the alternative is accepting
new connections whilst running as root.
And if you really want it to be that simple, a solution would be
to create a pre-packaged distribution that uses cgi+suexec to serve
static files.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
RE: vhost file protection (was: Inclusion of mpm-itk into HEAD)
Posted by Allen Pulsifer <pu...@comcast.net>.
> Folks want their static
> files to be owned by themselves, and not readable to random other
> users on the same system, but also serve-able by Apache. There are
> various user and group permission that can make this sort-of-but-not-
> quite happen, because whatever you do, someone can write a cgi
> program that can read your files.
Here's a set up I'm considering implementing to solve this same problem:
Every vhost is assigned a unique uid and gid. Let's call them uid=vhost and
gid=vhost.
Apache runs as uid=apache gid=apache.
The vhost's files and directories are set with uid=vhost and gid=apache,
permissions user read and group read.
Apache is able to read and serve the file by virtue of its gid.
When a cgi is launched, mod_suid is used to change the cgi process to
uid=vhost and gid=vhost. The cgi process is able to read the vhost's files
by virtual of its uid. However, it is not able to read any other vhost's
files.
Can you see any reason this would not work?
Re: Inclusion of mpm-itk into HEAD
Posted by Rich Bowen <rb...@rcbowen.com>.
On Jun 25, 2007, at 00:36, Graham Dumpleton wrote:
> A few comments below, but a few questions first to satisfy my own
> curiosity.
>
> What specific applications are you running that require things to be
> run as a distinct user? Are these applications implemented directly in
> C as custom Apache modules, or are you writing stuff in other
> languages, ie., such as PHP, Perl, running under mod_php or mod_perl?
> What are the perceived reasons that solutions such as mod_fastcgi,
> mod_scgi or the various mod_proxy type solutions wouldn't be a viable
> alternative for hosting your application?
It's a request that comes up every single day in the various support
forums: I am in a hosted environment, I have a virtual host, and a
bunch of random strangers have full read permissions to my sensitive
files, is there any way around this? So one of the main problems is
not applications at all, but is static files. Folks want their static
files to be owned by themselves, and not readable to random other
users on the same system, but also serve-able by Apache. There are
various user and group permission that can make this sort-of-but-not-
quite happen, because whatever you do, someone can write a cgi
program that can read your files.
So, in that situation, mod_fastcgi, mod_scgi, or whatever, are
completely ineffectual. Having a solution where FILES are read by
some other UID would solve this long-standing complaint.
Speaking only as help-desk personnel, and not as a code developer - I
have no insight into how this would be implemented, I only answer the
question, every day of every week for the last half-dozen years.
--
"There are two kinds of light--the glow that illuminates, and the
glare that obscures."
James Thurber
Re: Inclusion of mpm-itk into HEAD
Posted by Graham Dumpleton <gr...@gmail.com>.
A few comments below, but a few questions first to satisfy my own curiosity.
What specific applications are you running that require things to be
run as a distinct user? Are these applications implemented directly in
C as custom Apache modules, or are you writing stuff in other
languages, ie., such as PHP, Perl, running under mod_php or mod_perl?
What are the perceived reasons that solutions such as mod_fastcgi,
mod_scgi or the various mod_proxy type solutions wouldn't be a viable
alternative for hosting your application?
On 18/06/07, Steinar H. Gunderson <sg...@bigfoot.com> wrote:
> [Please Cc me on any replies, I'm not subscribed to the list]
>
> Hi,
>
> I'd like to request the inclusion of the ITK MPM (mpm-itk) as an official MPM
> in the Apache tree, for Apache 2.4/3.0. mpm-itk is basically a modified
> prefork allowing each vhost to run as a different uid/gid, ie. sort of like
> what perchild was supposed to do. The biggest differences between mpm-itk and
> perchild/Metux/peruser are:
>
> - mpm-itk is in production use at several sites -- for instance, most sites
> under .ntnu.no generally use mpm-itk, totaling about nine million hits a
> day. Even though it is still under experimental/ in the tree, most real
> issues have long since been ironed out -- it is not a proof-of-concept,
> but a real, working tool. It works flawlessly with SSL and most
> third-party modules (mod_ruby being a notable exception).
> - mpm-itk is not threaded, which means you can run the full range of evil
> third-party modules (such as PHP and its extensions) without problems.
Known not to work with current versions of mod_python. This is because
mod_python uses process mutexes for session locking between processes
and the changing uid of the processes causes problems with this.
Possible solutions have been discussed in:
https://issues.apache.org/jira/browse/MODPYTHON-202
> - mpm-itk does not require any sort of special kernel modules or
> configuration. It should generally work on the same platforms as prefork
> does, given that it's a direct prefork descendent. It's a pluggable
> replacement for prefork; most sites wouldn't really notice the difference
> if you took out prefork and replaced it with mpm-itk, until you start
> actually using AssignUserID. This provides a smooth migration path.
>
> Two main disadvantages should be noted:
>
> - setuid() happens after the request has been parsed, which means that the
> server runs as root up until that point. (However, on a system with
> capabilities, ie. Linux 2.6, almost all superuser privileges are dropped,
> so you can't just load kernel code or whatever.)
> - There is a performance drop from prefork, as each child is only serving
> one connection before it dies -- I haven't done any detailed benchmarking
> on this, but my general impression is: If you're serving static content
> and you're strained for performance, it matters. If you're serving dynamic
> content or large static files, it probably just disappears in the equation.
For mod_python based Python applications such as Django and
TurboGears, which have a memory footprint starting at about 7MB and
15MB respectively, any performance loss would not 'just disappear in
the equation" as the load time for each request would be significant
given that process would be thrown away after each request and
everything would need to be reloaded.
So for mod_python at least, this MPM would be totally impractical
anyway for anything but small applications even if the locking issue
were resolved.
Graham
> Despite these disadvantages, I believe it would be a useful addition to the
> upstream tree -- these are largely results of design decisions in order to
> keep the design as close to prefork as possible, instead of designing a new
> grand scheme that will take a lot of time to get right. mpm-itk is included
> in at least Debian, Ubuntu, Gentoo, and in FreeBSD ports, and based on the
> numbers from Debian's popularity contest (which is not a statistically valid
> sample, but nevertheless a good indication) is the third most popular MPM
> (after prefork and worker, but clearly ahead of event).
>
> The full set of patches, against Apache 2.2.3, is available from
>
> http://home.samfundet.no/~sesse/mpm-itk/apache2.2-mpm-itk-2.2.3-04/
>
> I'll of course be happy to update these to apply against HEAD if needed,
> transfer copyright to the ASF, and write any needed documentation. However,
> given that the "runs as root" issue has proved somewhat controversial
> earlier, I don't think it's appropriate to do that kind of upstream
> integration work before some kind of decision has been made :-)
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>