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/
