mark benedetto king wrote:
> 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).
i don't think apr currently supports AF_UNIX, although people have
talked about adding that support.
> 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).
i would very much prefer that it be auto started... having to configure
a daemon for a local repository is just too much to ask from users.
> 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.
i'd love to see this. i'm not positive it's the best plan, but it
sounds like a viable option to provide if nothing else.
speaking of ra_pipe, when do we get to see some more of that code in the
tree? ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 19 21:01:59 2002