[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mono-devel-list
Subject:    Re: [Mono-dev] Open discussion for mono setuid per vhost
From:       Robert Jordan <robertj () gmx ! net>
Date:       2005-12-28 1:01:12
Message-ID: doso4o$pkl$1 () sea ! gmane ! org
[Download RAW message or body]

Christopher,

> So far I've been discussing this offlist with another Mono/.Net 
> developer...  I'm interested in open/honest feedback or code snippets 
> which might help accomplish this..
> 
> So far there are two ways which seem reasonable so far and please pardon 
> me if I'm missing some points..
> 
> 1) Mono wrapper
> 
> Apache ---> mod_mono -->  mono-server-path to wrapper --> mod-mono-server
> 
> The wrapper is s+ (sticky bit) and owned by root.. It then calls the 
> mod-mono-server with setuid as the desired user..

This is quite secure, but it probably won't work from scratch
due to the unix socket used for the mono_mono <-> mod-mono-server
communication.

> 2) Patching mod_mono directly..
> 
> Apache ---> mod_mono_patched --> mod-mono-server
> 
> With the 2nd approach I'm thinking I have to compile mono with 
> -DBIG_SECURITY_HOLE (have to love the naming convention) and start 
> apache as root.. and then let mono setuid during the fork..
> 
> This has two big disadvantages that glare at me.. -DBIG_SECURITY_HOLE is 
> named appropriately, but is owned by root and setting +s really any 
> different.. Also then I have to maintain a patchset that is off mainline 
> unless it's somehow contributed upstream.. (Is the -DBIG_SECURITY_HOLE 
> and starting as root a must?)

Yes, it is.

> I'm really not seeing a maintainable way to get around the vhosts being 
> in their own environment issue.. (Just when I thought I had it whipped 
> something didn't seem right.)  the end goal is to provide the following..
> 
> a) Each vhost being under it's own user
> b) If a vhost crashes it automagically restarts
> c) Allows apache to serve the static content (keep some of the load off 
> XSP for things like images, css and etc...)
> d) Minimizing memory overhead impact if the vhost counts goes into the 
> hundreds..
> e) Not using proxy

FastCGI + Apache SuEXEC might be a solution as well, at least it covers
a-e. It is used for PHP by serious mass hosters.

However, it requires a new "fastcgi-mono-server", which has to be
developed.

> (On startup which even with -aot on everything seems to take the load 
> average to some really high levels if you start a lot of mod-mono-servers)

Gonzalo is aware of this issue.

Robert

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]