Re: chroot issues and http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity .html

[Alfred M. Szmidt]

       But since you cannot escape a sub-hurd currently, it has limit
       use; one cannot run for example a web server inside a sub-hurd
       for security reasons, since you cannot send things outside of
       the sub-hurd (no access to the network).

   Now we are getting at the real issues.  For most purposes, we would
   need the sub-hurd to allow certain limited ways of writing data out
   of the sub-hurd.

   Would you like to work on implementing such facilities for
   sub-hurds?

Not enough hours in the day for this, maybe someone else would like to
take a crack?

       It just occured to me that another way to allow a sub-hurd to
       communicate outside of its enviroment is to run a server
       outside the enviroment, that listens and intercepts
       communication, and injects messages into the sub-hurd
       enviroment.

   I do not really understand what that means.  Could you describe it
   in more detail and more concretely?

Since one can access all processes that are running in a sub-hurd from
the main system (say, using gdb), one could have a special program,
that listens to the messages that process sends.

Now say that you wish to allow network communication to be allowed
from the sub-hurd, you'd attach this `proxy server' to the network
stack process that is running within the sub-hurd.  The proxy server
would then listen, and forward all communication (at the same time
maybe sending modified messages) to the real network stack process
(the one in the main hurd).

I hope this explains the general idea, how one would go about actually
implementing it (let alone if it is really possible) is a different
story.  A good first step would be to hack GDB so that it can trace
(this is easy), and modify messages (this is harder).

Happy fluting.