Openssl and rsync

[jw schultz]

On Wed, Jun 18, 2003 at 09:17:03PM +1000, Martin Pool wrote:
> On 20 Feb 2003, Lee Wiltbank <lwiltbank at novell.com> wrote:
> 
> > I have been working on a project to Openssl'ify Rsync.  I am having
> > problems when Rsync forks two processes to handle a sender and was
> > wondering if anyone else would be able to lend a hand or some
> > pointers.  I have posted to mailing.openssl.dev 
> > 
> > Basically, I have brought up Rsync 2.5.5 on cygwin.  It goes through
> > the Openssl init and then waits on accept.  When it accepts, it forks
> > itself.  The child then communicates with the other side.  The problem
> > occurs when Rsync determines that it is the receiver and forks itself
> > again.  Then there are two processes with the same SSL object.  I
> > am having a lot of trouble getting data from the client once Rsync
> > does this two-fork thing.  I know that Openssl is multi-thread
> > capable, but this situation is where two processes have the same
> > SSL object and attached socket and are working with it.
> > 
> > This version works fine when Rsync is the sender, that is, the client
> > connects and the server sends the files over.  In this case, there is
> > only one process trying to write to the SSL object and socket.
> 
> There are a few difficult historical facts, as you say
>  
>  - Forking on the receiver is pretty tightly embedded into the
>    application and protocol.
> 
>  - OpenSSL just cannot handle a single socket being used from two
>    different processes.  Unlike with threads, it does not have any
>    easy place to keep common state.  And in any case the two processes
>    assume they can just do their own thing; I'm not sure they would be
>    able to synchronize in the way required by SSL.
>    
>    Consider that a "write" operation  from the applications point of
>    view may result in several reads and writes in the SSL layer, and
>    vice versa.
> 
> None of these issues are absolutely insurmountable (it's just code)
> but they are pretty tough.  My recommendation is not to waste your
> time.
> 
> Therefore one might look at putting SSL in a separate process that
> stands between the real socket and rsync.  You could fork this off
> just before starting processing, perhaps in response to a command line
> parameter.
> 
> Or you could just use stunnel, which does essentially this only with a
> bit more manual setup.
> 
> SSH already works and is at least as easy to set up as SSL.  (Key
> management is far more practical.)  Is SSH not available on Netware,
> or are there issues with it?

As i understand it from my own observations in the past and
confirmed by Lee ssh isn't available on Netware servers.
It wouldn't make sense to have ssh since there are no
shells in the UNIX sense.  There is a CLI but its nearest
equivalent is interactive lpc.

They don't have the kind of process model that POSIX
specifies so forking and IPC are problematic.  The Netware
port involved converting rsync from a forked model to a
threaded one.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt