On Fri, 2006-04-21 at 13:29 -0400, Ethan Blanton wrote:
> No, not at all like that. I would rather, as the previous poster
> suggested, usher received the incoming data, and rather than spawning
> the monotone server directly (as it does now), it requested a
> privileged process to spawn the monotone server on its behalf and then
> communicated with that server.
Usher is reorganized on branch net.venge.monotone.contrib.usher in such
a way that this shouldn't be too hard to do.
> The extra security comes in in that the usher server which listens to
> the outside world and the privileged server cooperate in a very simple
> and well-defined manner (e.g., perhaps the listening server sends
> simply a tuple of {hostname, collection} to the privileged server, and
> receives a port number in return). I believe netsync cannot be
> considered a simple and well-defined manner.
Usher allows for asking the status of a server, allowing/not allowing it
to receive new connections, and closing idle servers. In the rewrite,
servers are hidden behind a server_manager class, which has 8
"interesting" public functions. At least 3 of these would have to talk
to the priviledged process (reload server list, connect to server, kill
idle server). I *think* the others could avoid this.
Tim
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
