The following paper was originally published in the Proceedings of the Fifth USENIX UNIX Security Symposium Salt Lake City, Utah, June 1995. For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: http://www.usenix.org File-Based Network Collaboration System Toshinari Takahashi, Atsushi Shimbo, and Masao Murota Communication and Information Systems Research Labs. TOSHIBA R&D Center 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki 210 Japan {takahasi,shimbo,murota}@isl.rdc.toshiba.co.jp Abstract Computer-Supported Cooperative Work (CSCW) requires coordinated access to shared information over computer networks; such networks have tended to use wires, but wireless networks are now becoming common. There are a large number of tools aimed at helping users to work cooperatively but these tend to be application specific, leading to proliferation and requiring a large amount of development effort. A more general purpose mechanism would keep the number of tools manageable, and would obviate the need to develop a completely new tool for each problem area. Data security is also a very important requirement in distributed systems. A solution to the problems of cooperative working must take this security requirement into account. This paper describes a mechanism aimed at both problems: a general purpose tool for cooperative working that is more secure than existing proposals. Our approach is novel in that we do not require explicit locking, which can lead to a number of problems, particularly in distributed systems, as we shall explain. Client routines act upon user requests to insert or delete blocks in a file, and request a file-server to modify a shared file according to those requests. The file-server receives encrypted requests asynchronously and merges these requests into the current version of the document without decrypting the requests. Indeed, an interesting feature of our proposal is that the server could not decrypt the content of these requests even if it wanted to. We call this mechanism "privacy enhanced merging". Our current implementation includes a concurrent editing application that we call "Network BBS"; the server is able to make use of a conventional file-system. This is an experimental tool of our proposed "Collaborative File System". 1. Motivation Shared-data management systems have to be able to cope with recent advances in computer and network technology, such as CSCW over networks, wireless networks, and version-control mechanisms. They also have to be able to take into account security requirements such as data encryption and user authentication. Actually, we often meet such situations when we want to allow a person who does not belong to our domain to edit a specified file we own without giving a user account on our domain. Our approach to these problems is a novel file system architecture which provides an asynchronous editing mechanism and encryption facilities. Network distributed file systems allow users to share read-access to files, but concurrent modification of those files is more cumbersome. Traditional approaches to this problem include the use of a locking mechanism to provide mutual exclusion, but for various reasons this is often inconvenient. For example, a user wishes to modify a file and so acquires the lock and starts an editor (in practice the editor is likely to acquire the lock on the user's behalf); while the user holds this lock nobody else may access the file. Alternatively, a user wishes just to read the file and so does not take out an exclusive lock; he then realizes that he needs to change the file, but in the meantime others have modified the file under his feet. Sometimes these problems are merely a nuisance, but sometimes they can lead to the destruction of valuable information, particularly if users are tempted to override the locking mechanism because of its inconvenience. Previous work concerned with such problems has focused on the provision of a comprehensive library of editing primitives [1]. Our system does not require a user to take out an exclusive lock when he or she wishes to modify a file, nor will he or she be frustrated by finding that somebody else holds such a lock. Users take local copies of a file and operate concurrently on those; a file comparison utility such as "diff" [2] determines what changes were made. This allows users to continue to use their favorite editors, such as "vi" or "emacs". The client sends a list of differences, insertions and deletions, as modification requests to the file server. Requests are sent to the server asynchronously and the file server merges these requests into appropriate positions in its stored version of the file. This uses information we call "target versions" which we shall describe later in this paper. A similar approach was used for the CVS system [3]. We realize that our approach does not use a strict consistency mechanism, but instead relies upon a certain amount of common sense on the part of the users. IoseoseooCoCoCC4kanetw alverysout bloblob Mir ir i‘BBBificificiten artSly used approach to the problems of confidentiaiaiied aed aeion ion iacsacsapurplocalocalt watioitond tSlstributed proideing. Io p p lar offers no facilities aimed at cooperative working. Rather than follow the he happroach we have chosen to fofof the example of CFS [5], which delegates responsibility for confidentiality to the file system r r er er ea mail system. We note that in the simple case we wee a user does not need to cooperate orve wounicate with anybody elseion ihis provides conconchave have hty where the he hrovidradigm would appear most inar tpriate.