The following paper was originally published in the Proceedings of the 2nd USENIX Windows NT Symposium Seattle, Washington, August 3–4, 1998 SecureShare: Safe UNIX/Windows File Sharing through Multiprotocol Locking Andrea J. Borr For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org/ SecureShare: Safe UNIX/Windows File Sharing through Multiprotocol Locking Andrea J. Borr [email protected] file sharing altogether. These differences in the han- Abstract dling of locking and file sharing issues carry over into the designs of the NFS and CIFS protocols used by As mixed UNIX/Windows environments become more UNIX and Windows, respectively, for remote data ac- common, safe file sharing among the NFS and CIFS cess. For example, CIFS transmits file open requests clients becomes a significant problem. In this paper, and byte-range lock requests to the file server, whereas we describe SecureShare, a multiprotocol file sharing NFS does not. technology that resolves the mismatch between NFS/NLM and CIFS file locking protocols, provides Correct interoperability of CIFS and NFS/NLM is im- coherent caching and enables multiprotocol change peded by the fact that CIFS and NFS/NLM have differ- notification. SecureShare achieves the goal through a ent and incompatible semantics for file-locking, file- uniform lock-mode model and multiprotocol oplock open, and file sharing. The two principal management. This paper presents the main features of interoperability problems are (1) CIFS mandatory SecureShare and discusses the rationale behind its de- locking vs. NFS/NLM advisory locking; (2) CIFS hier- sign. archical locking vs. NFS/NLM non-hierarchical lock- ing. 1. Introduction CIFS requires that the file server and all of its clients Today, mixed UNIX/Windows environments are be- conform to the mandatory locking model. In the man- coming increasingly common. Many commercial and datory model, the file opener’s (alternatively, the byte- academic institutes typically employ a mixed network range lock owner’s) exclusivity of access to the opened of UNIX clients using the Network File System [3] file (locked byte-range) is enforced by the file server at (optionally with Network Lock Manager [5]) and Win- the system level. dows clients using either the Common Internet File By contrast, NFS/NLM lacks file-open functionality, System [6] or “(PC)NFS” [7]. Sharing files across the and provides only advisory locking. In the advisory different systems is highly desirable and commonly model, system-level enforcement is replaced by appli- done. However, correct concurrent read/write accesses cation-level compliance. In this environment, each of a from the different types of clients present a significant set of applications that read and write shared data de- problem, because of the mismatch between NFS/NLM pends for its correct functioning on global compliance locking protocols and CIFS locking protocols. with advisory locking rules. Uncoordinated concurrent read/write accesses to files In a mixed CIFS and NFS/NLM network, the incom- and directories can result in application failures or file patibility of the mandatory and advisory models poses a data integrity problems. Examples of such problems risk to data integrity. Windows-based applications de- are (1) readers receiving “stale” data (i.e. data cur- pend on the stricter CIFS mandatory model for their rently in the process of being updated by another appli- correct functioning and for the integrity of their data. cation), (2) writers overwriting each other’s updates, These applications may fail in the face of NFS accesses and (3) applications having their in-use files deleted that write, remove, or otherwise corrupt in-use Win- “out from under” them. Locking is typically used to dows files in a manner that violates the stricter CIFS coordinate concurrent accesses to files and directories, mandatory model, but is permitted under the looser and prevents such problems from occurring. NFS/NLM advisory model. Unfortunately, Windows and UNIX differ considerably The second problem impeding correct interoperability in how they allow applications to access files and data of CIFS and NFS/NLM is the fact CIFS expects all cli- while controlling the concurrency issues that arise in ents to conform to a hierarchical locking model. Cor- multi-user, multi-application environments. Windows rect application functioning and data integrity under implements a robust and complete set of file-open, data CIFS rest on the assumption that a client first acquires a access and locking paradigms. UNIX, by contrast, file-lock (i.e. by opening a file) before requesting a typically implements only a basic data access facility, byte-range lock within the file. The NFS/NLM proto- ignoring for the most part issues of concurrency and col, on the other hand, has no concept of a locking hier- archy. NFS/NLM has provision for acquiring a byte- with respect to NFS reads and writes, in accordance range lock on a file, yet lacks provision for pre- with NFS/NLM protocol standards. acquiring a file-lock on the file by opening the file. The cornerstone of SecureShare is a multiprotocol lock Network Appliance’s solution to these problems is Se- manager. The lock manager coordinates and manages cureShare [1], a multiprotocol file sharing technology. — in a unified set of kernel-space data structures — the SecureShare is integrated into the Data ONTAP mi- lock types needed for multiprotocol file-open and crokernel, Network Appliance’s operating system for locking support. Since it is integrated into the Data its proprietary file server appliance, or filer [2]. Secure- ONTAP kernel, the lock manager is able to validate that Share provides correct semantics for file sharing, op- reads and writes of files and directories do not violate portunistic locking, byte-range locking, coherent cach- locks. SecureShare enforces CIFS locks and file-open ing, and change notification in a mixed network of semantics at the system level. By contrast, in a UNIX- UNIX clients using NFS, optionally with NLM, and based CIFS implementation such as Samba [9], Win- Windows clients using either CIFS or (PC)NFS. dows file-open information is maintained by a module The key features of SecureShare are: that is disjoint from — and has no interaction with — the module that implements UNIX and NLM locking • uniform lock mode and multiprotocol lock en- functionality. Moreover, because data access functions forcement under UNIX do not normally check for lock conflicts, • multiprotocol oplock management there is nothing to stop local or NFS-based UNIX users and applications from accessing, corrupting, or even • multiprotocol change-notify. removing “locked” Windows files and data. Thus, it is In implementing multiprotocol data integrity, Secure- possible in such an environment for UNIX users or Share reconciles the different and incompatible locking NFS clients to write, remove, or move files that CIFS- and file-open semantics utilized by CIFS and based Windows applications are holding open and ac- NFS/NLM clients. In implementing multiprotocol tively accessing. oplock management, SecureShare supports standard SecureShare implements a multiprotocol extrapolation CIFS oplocks, while at the same time making oplocked of the Windows coherent caching and networking per- data available to NFS-based clients through multiproto- formance optimization known as “opportunistic locks” col oplock break. In implementing multiprotocol (oplocks) [6]. By extrapolating oplocks to the multi- change-notify, SecureShare supports standard CIFS protocol environment, SecureShare allows CIFS clients change-notify, while extending the change-notification to safely reap oplocks’ performance benefits of aggres- service such that it covers changes due to NFS in addi- sive client-side caching without causing Windows ap- tion to covering changes due to CIFS. plications to suffer the effects of potential data corrup- SecureShare implements a uniform set of file-locking tion due to uncoordinated NFS accesses. By allowing semantics for the multiprotocol environment. To non-CIFS requests to break (i.e. revoke) CIFS oplocks, achieve consistent multiprotocol locking and file-open SecureShare ensures that oplocked file data remains semantics, SecureShare manages all locks according to available to NFS-based applications and users, while a uniform lock management model. In this model, an simultaneously protecting the integrity and cache co- expedient described in Section 2.2 is used to overcome herence of that data. the interoperability problem posed by the hierarchical locking conformance mismatch between CIFS and The remainder of this paper is organized as follows. NFS/NLM. Uniform lock management also solves the Section 2 discusses file and data locking paradigms in interoperability problem posed by the mandatory vs. the CIFS, UNIX/NFS, and (PC)NFS environments, and advisory mismatch. Lock enforcement under Secure- presents the uniform lock-mode model in SecureShare. Share depends on the lock type, the protocol that set the Section 3 discusses multiprotocol lock enforcement. lock, and the protocol performing a file access. Whole- Section 4 discusses the CIFS opportunistic locking file locks (representing file-opens and oplocks) are en- model and SecureShare’s multiprotocol implementa- forced uniformly on the mandatory model for both CIFS tion. Section 5 discusses the CIFS change-notify fea- and NFS file accesses.