On Thu, Sep 19, 2002 at 10:24:19AM -0700, Bill Tutt wrote:
> >
> > You are seriously proposing a root process that kills other processes?
> > Including my Subversion aware editor which happens to be accessing the
> > repository? And my debugging session which happens to have reused the
> > crashed Subversion client process ID? This is a "completely and
> > utterly robust" solution?
> >
>
> Well, we must do something.
>
> Alternative suggestions that do solve the problem are certainly
> welcomed.
>
> Bill
>
Well, what oracle does (AFAICT) is this:
1.) clients connect to a socket (AF_UNIX preferred, AF_INET okay).
2.) the listening on the socket forks of a child to service
this connection, which is used for an entire transaction (and
possibly more than one transactionj).
3.) the child then reads queries from the client, executes them,
and writes the results back. If the client dies, the child detects
this easily, and rollsback the outstanding transaction, releases
locks, and exits.
The code for this child process is extremely thoroughly QAed
so that it, itself, is unlikely to fail without releasing the
locks that it holds. Further, the listener mentioned in (2)
can detect when this (extremely rare) failure happens, and DTRT.
I think this may be the easiest safe strategy (though it does
require a daemon) (which might be auto-started, as mentioned
before).
It is easy to only start one instance of the daemon: only one
process can bind to a particular socket at once.
I don't think it needs to be setuid; it doesn't matter who owns
the daemon (any local user with write access can own the daemon).
One could argue that there are some security problems with this
approach (a local user could create a hostile server to attempt
to exploit a client-side vulnerability). If this is a concern,
then make the repo owned by svn and mode 600 and start the
daemon ahead of time, or make a setuid daemon-starter.
Of course, this requires that an API be marshalled
into flattened queries" and responses so that this communication
can take place over the socket connection.
From a QA standpoint it might be easiest to do it by making
an RPC-style wrapper around the BDB API. We can even use
the xmlrpc-epi library for marshalling of the requests;
I've done the majority of the work necessary for this already
for ra_pipe; I even have an IDL compiler. :-)
Unless there are objections, I can probably throw this together
in a day or two.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 19 20:56:10 2002