PSARC 2008/212 Integrate Unison into Solaris

[Joerg Barfurth]

I did some work with unison a while back. Actually I had started 
preparing a case like LSARC/2006/222 which would have brought unison 
onto the system, but that project never got far enough (I believe 
LSARC/2006/222 is the result of a successor project).

 From that background some remarks, particularly with a view on 
interface stabilities:

Garrett D'Amore schrieb:
> Frank Che wrote:
>> 4.2 Security concerns:
>>     Security becomes a concern when synchronizing files across network. Unison
>>     provides two methods for communicating between the client and the server:
>>
>>     * Remote shell method: To use this method, you must have some way of
>>     invoking remote commands on the server from the client's command line,
>>     using a facility such as ssh. This method is more convenient and also more
>>     secure (especially if you use ssh).
>>
>>     * Socket method: This method requires only that you can get TCP packets
>>     from the client to the server and back.
>>     The socket method is insecure: not only are the texts of your changes
>>     transmitted over the network in unprotected form, it is also  possible for
>>     anyone in the network to connect to the server process and read   out the
>>     contents of your file system! The socket method is provided only for
>>     expert users with specific needs; everyone else should use the remote
>>     shell (ssh) method.

> I presume that if there is a server here, it is not enabled by default?  
> Can you confirm, does this project adhere to the Secure By Default rule?
> 
> If there is a server, how is it administered, if at all?
> 

That server isn't configured to be started by the system at all. unison 
is intended as a user-level tool. You'd start unison with the options to 
make it a socket method server manually under whatever user account has 
the right access to the files you want to synchronize. You could create 
a real service harness for this, but that is not part of the normal 
unison setup and not recommended for security reasons.

The main use case for the socket method is synchronizing with a peer 
that does not have a ssh server or client readily available (e.g. a MS 
Windows box in the server role or owned by someone who can't be bothered 
to install an SSH client).


>> 4.3 Limitations:

> 
>> 4.3.4 Unison does not understand hard links.
> 
> That's pretty unfortunate.  I guess the necessary consequence of this is 
> that Unison my dramatically increase the bandwidth needs and storage 
> needs on the remote side.  Imagine synchronizing a 4G ISO image, which 
> also has hardlinks to other names -- instead of transferring and storing 
> one 4G image, you are transferring and storing n * 4G.
> 
> Can this result in previous hard links being busted?  Will updates 
> copied from one file on a remote node potentially clobber a hard-linked 
> clone elsewhere?  (Put another way, if a file A is hardlinked to file B, 
> and a remote copy of A called C is updated, will the synchronization of 
> A from C by Unison cause any change to B?)
> 

I think part of the reason or this (and also of lack of ACL support, 
etc) is that unison tries to be able to operate across platforms. The 
more features are included that are not available or not the same on all 
file systems the harder it gets to do a decent handling/mapping when 
synchronizing between different file systems and platforms.

The restrictions are documented and if you rely heavily on hard links, 
this tool may not be for you.


>> 4.5 Interfaces
>>
>> 4.5.1 Imported Interfaces
>>     +------------------------------------------------------------------+
>>     |        NAME           | STABILITY LABEL |       DESCRIPTION      |
>>     +-----------------------+-----------------+------------------------+
>>     | libsocket             | Committed       | PSARC/1995/014         |
>>     +------------------------------------------------------------------+
>>
>> 4.5.2 Exported Interfaces
>>     +------------------------------------------------------------------+
>>     |        NAME           | PROPOSED        |      DESCRIPTION       |
>>     |                       | STABILITY LABEL |                        |
>>     +-----------------------+-----------------+------------------------+
>>     | SUNWunison            | Uncommitted     | Unison package         |
>>     |-----------------------+-----------------+------------------------|
>>     | /usr/bin/unison       | Committed       | Unison executable      |
>>     |-----------------------+-----------------+------------------------|
>>     | ~/.unison/default.prf | Uncommitted     | Unison default profile |
>>     +------------------------------------------------------------------+
> 
> I probably shouldn't repeat this, but I am again concerned about 
> Committed for an application that seems to have a somewhat limited 
> audience and may itself no longer be actively developed or maintained.  
> (See http://www.cis.upenn.edu/~bcpierce/unison/status.html for that 
> status information.)  This is all the more so given the above 
> limitations, which it now seems are unlikely to be resolved given the 
> development status.
> 

Interestingly that status page does not really reflect recent practice. 
The statement that unison is in maintenance mode has been up for several 
years and in the timeframe I observed it, unison has progressed from 
version 2.9.x to 2.27.xx with several intervening beta versions and 
bugfix updates. So the maintenance has been relatively active. On the 
other hand the status statement indicates that the primary maintainers 
may stop their part of this activity at any time at their discretion, so 
I too would be wary of putting a Committed stability on unison.

But there is another pitfall to keep in mind when assigning stabilities 
for unison: the fact that there still is (or at least has been) active 
development, so there may be more upstream version changes.

unison has a very limited compatibility promise for its transfer format. 
That means that two different unison versions won't talk to each other. 
Currently (iirc since 2.17) versions are different for this purpose, if 
they differ in minor version number - i.e. version 2.27.xx will work 
with 2.27.yy but not with 2.17.zz. IIRC the technical reason is that 
they use OCAMLs builtin serialization for some internal objects, so 
whenever they add fields to these objects, the protocol changes.

Apparently 2.27 has been around for a while, but the 2.10.x version I 
worked with ~4 years ago is completely gone from their download page. 
They appear to do limited bugfixing on the prior stable revision (2.17).

For that reason I would have proposed a versioned file name (e.g. 
/usr/bin/unison-2.27), so that versioning-skew-proof configuration of 
unison profiles is possible (you can specify the name of the server-side 
executable) and to keep stability at no more than Uncommitted. Whether a 
/usr/bin/unison symlink (with even lower stability) makes sense could be 
argued.

Profile capabilities evolve with versions too, but afaict the unison 
project has a pretty good track record of maintaining compatibility there.

- Jörg

-- 
Joerg Barfurth           phone: +49 40 23646662 / x66662
Software Engineer        mailto:joerg.barfurth at sun.com
Desktop Technology       http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/