Dave Dykstra <[EMAIL PROTECTED]> writes:
> This was originally posted to the lsh mailing list, and I am expanding
> it to also include the rsync mailing list.
>
> Niels: the primary author and current maintainer of rsync Andrew Tridgell
> is away for a while so he probably won't be able to answer this very soon.
> I was maintainer of rsync for a while and have some suggestions for you.
Thanks. I'll try to subscribe to the rsync list as well.
> > I'd like users to be able to export files using lsh's user
> > authenticatin mechanisms and spki certificates (lsh's spki support is
> > currently very limited, but that should also change). This way, a user
> > can grant read or write access to some of his/her files to a certain
> > key (or "spki principal"), for some period of time, and the owner of
> > that key can also delegate some or all of that access further.
[...]
> I'm sorry to tell you that a spec for the rsync protocol itself does not
> exist because there really can't be one. The protocol used by the rsync
> program is not designed to have multiple implementations, it is a highly
> packed protocol that really only works because the same code is used on
> both sides. The protocol also keeps getting revised (currently at revision
> number 24) and the implementation is full of places checking the other
> side's protocol version number to make sure the other side is talking the
> same protocol.
Hmm. This sounds a little messy. I'm an outsider here, but if I may
suggest a course for action, I'd would really wish for two independent
protocols:
S. A nice clean protocol to do the rsync stuff (i.e. transfer of
files, listing of files. Or any other features that I don't know
about. This protocol may well be a little verbose.
T. A transport protocol, that performs things like version
negotiation, user authentication and compression method
negotiation (typically zlib). At the end of the handshake, this
protocol provides a bi-directional (possibly packet oriented, if
that is preferred), typically compressed, channel over which the S
protocol can be used.
Do you think such a division would hurt rsync efficiency? The nice
thing about this is that applications that already provide things like
compression and user authentication can use the S protocol only.
The rsync application could have some options for using either the T+S
protocol or only S.
> I do think that there is a need for more secure access on the rsync server
> side for cases when users do not have logins on the servers. Currently
> clients cannot be guaranteed that the server is not being spoofed, and the
> only authentication of clients on the server is password based (although it
> is a challenge-based password scheme; passwords are not sent in the clear
> over the network) coupled with some tcpwrapper-style limits on hosts.
> Clearly there would be some benefit from doing public key authentication in
> both directions, so an integration with lsh seems like a good idea.
Secure access for users that have a real account should be easy: It
should just be a matter of setting RSYNC_RSH=lsh. Secure but anonymous
access might be easier to do with SSL than with with the secsh
protocol.
> My suggestion is to not try to re-implement the rsync protocol in lsh, but
> instead design some sort of interface between the lsh server and rsync, so
> that authentication information can be passed from the lsh server to the
> rsync server code, and then let rsync take over to do the data transfer.
> I haven't thought through the details, but it seems like a more workable
> approach.
For the case of fine-grained delegated access to some files, I'm
afraid that I would want do write a specialized rsync server. Note
that this is a specialized case, mostly orthogonal to using
RSYNC_RSH=lsh, and it doesn't necessarily have to use the same
protocol. This is where a protocol like S would make sense.
At last, even if there are no detailed protocol spec, could you give
me an overview of the high-level operations in the protocol? As far as
I can understand, it ought to be something like
GET file
PUT file
LIST some/path/or/pattern
(although in a more compact form). How GET and PUT work is explained
well in the tech-report. Some remaining questions are:
How powerful commands do you have for listing files?
Are there any other features in the protocol (say chmod, rename)?
Are there different commands for overwriting files and creating new
ones?
When updating a file, there ought to be some flexibility about which
file is used as the "old" version. For instance, when trasferring a
new file lsh-0.9.1.tar, it might be a good idea to use blocks from
lsh-0.9.tar in the rsync algorithm.
Is there any special magic to deal with gzipped files, using blocks of
the *uncompressed* files for the rsync algorithm?
I would appreciate some guidance before I start reading the source
code.
Best regards,
/Niels
