Common Internet File System – John Hamill #97361925

Common Internet File System
John Hamill #97361925

Introduction:

The Common Internet File System or CIFS is Microsoft’s answer to the problem of distributed file systems over the Internet. Like Sun Microsystems’ WebNFS, CIFS is based upon a pre-existing network file system for local area networks that the designing company created. In this case it is the SMB and NetBIOS file sharing protocols which have been part of all Microsoft’s Operating Systems for several years. CIFS is an extension of the SMB protocol optimised for the Internet.

The SMB protocol that CIFS is based upon has been standardised by the Open Group since 1992 for PC to Unix connectivity (X/Open CAE Specification C209). SMB is designed to allow file and printer sharing across local area networks or LANs. CIFS extends this idea to the Internet and has been submitted by Microsoft as an Internet-Draft document to the Internet Engineering Task Force (IETF) with a view to being published soon as an RFC for full cross platform standardisation.

The aim of CIFS is to provide a remote file access (printers are treated as files) protocol over the Internet. It is designed to allow connections over both UDP and TCP, but the predominant use would be over TCP on IP. CIFS is supported by all Microsoft operating systems and like it's predecessor SMB is supported on a wide range of other platforms including Unix and VMS.

Technical Discussion:

CIFS's Central Design Strategy revolves around a protocol that is compatible with how applications already share files across local disks and LANs. It allows global naming, remote file and printer sharing, extended file attributes, file and record locking, caching, volume replication and it supports Unicode filenames.

The following sections describe these key features of CIFS and their uses.

Naming Conventions:

Unlike SMB which is limited to a flat name space, CIFS utilises the Internet Domain Name Service to resolve hosts for file access. So whereas an SMB access to a remote file is of the form:

"\\ServerName\Directory\Filename"

within a certain domain, CIFS allows you to potentially access a file on any system that is connected to the Internet using the form:

"file://ServerName.Domain:Port/Directory/Filename"

Because of this ability to use the Internet's naming system, CIFS is far more scalable than the older SMB protocol which was designed soley for LAN use. Instead of hundreds of users, CIFS can potentially connect millions.

File & Printer Sharing:

File and printer sharing is carried out by CIFS in a method that is transparent to the application. A user can print to a machine they have access to across the world just as easily as they can to a local printer. Using the above mentioed naming convention the user can specify either local file or printer or one that is located in a different building or a different country.

Extended File Attributes:

One of CIFSs key features is the ability to for the server to add additional information to a file's record such as a content dscriptor, or author name. These can be used by the server to support any form of access restrictions that a client might require. For example the extended file attributes might be used to support the standard Unix Read-Write-Execute-User-Group-World access restrictions, or instead could support the more flexible Access Control Lists used by VMS.

Since the extended attributes are not defined within the protocol, but rather as descriptors similar to HTTP MIME tags, they can be extened in the future in any necessary way and are not tied to a specific methodology unlike the Unix system, which is used by NFS and WebNFS. CIFS is the first file system to support this property, giving it an edge over both WebNFS and AFS.

File and Record Locking:

CIFS supports three types of locking on file access order to maintain a file's integrity which can potentially be upset by non-locking systems such as Sun Microsystem's NFS which operates on the assumption that two users will never be writing to a particular file at the same time. This is a dangerous assumption which cannot hold in an environment with thousands or millions of users such as the Internet. The methods that CIFS chooses to use to ensure data integrity are as follows:

Exclusive Locks: These locks give a client exclusive access to a file allowing it to do full read and write caching sure in the knowledge that it is the only accessor of the file. Any other client that tried to access the file while it is locked has its access denied. The lock is broken when the accessing client sends its updated data and signals that it has finished. The server then makes the file available for all to access again.
Batch Locks: These locks limit the amount of network traffic caused by applications which open and close the same file multiple time for read or write access. As long as no other client tries to access the file the application can perform all its operations from a local cache reducing the amount of file-open and file-closes that need to be sent across the network. When another client does attempt to access the file the server signals that the client must finish its batch access and send any updates to the server, and then switch back to normal (i.e. more network traffic) access for the file.
Level 2 Locks: The last type of lock supported by CIFS allows multiple clients to have access to a file for read access only. Clients can perform read caching on the file to improve network performance. However if any client tries to access the file for write operations the server informs all the connected Level 2 Lock clients that the lock has been broken, and therefore that their read ahead information is now out of date. The clients then revert to normal (non-cached) network file access until the writing client has finished and they can re-accquire a Level 2 Lock.

These methods of file locking prevent clients from having different versions of files and so prevent the NFS problem of two clients both updating a file thereby overwriting one another's updates.

Caching / Versions:

CIFS allows clients to perform caching depending on the locks they have accquired. For example a file with an Excluse Lock (See above) can perform full caching of a file on local storage until such time as it has finished with the file, whereupon it clears its cache copy. Files which do not write to a file can accquire Level 2 Locks allowing them to cache files for read access only. The server informs the clients when the cache copy that they posess is out of date due to write access by another client. These caching methods reduce the network traffic overhead. Although it requires that the server maintain state information on clients, CIFS allows more efficient network usage than non-state systems.

Security:

CIFS supports two methods of controlling access to resources on the network, Share Level and User Level. These two methods are inheirited from SMB and work as follows:

Share Level: This method assigns passwords for access to a particular resource. For example a file on a certain server may be assigned one password for read access and another for read-write access. This method is potentially less secure than the second method since ANY user with the address of the resource and the password to it can access it from anywhere on the network.
User Level: The second method of restricting access to resources involves using User IDs and passwords which the server verifies before access is granted. This therefore allows only those who are known by the server to access resources on it. Lists are maintained on the server of which resources a user is allowed to access. This also allows easy administration of who can access a resource without having to change all the passwords everytime someone no longer has access to that resource. Guest accounts with default access can also exist.

For password authentication and data transfer CIFS uses the DES protocol as standard, which is secure enough for non-critical data, but can be augmented at the application level by any additional encryption required. CIFS uses a 7-byte key(56bit DES) for encrypting every 8-bytes of the data stream, though longer keys may be used as required, with no specified maximum.

Volume Replication:

This allows CIFS servers to dynamically assign users to less loaded mirror servers in order to better make use of server capacity. The server finds the best mirror server for a client which is necessary when you are receiving many thousands of accessess per second and is preferable to allowing only a limited number of clients to connect. The problem of synchronising between servers is computationally expensive but worth the cost in order to maintain service to clients.

Unicode Support:

CIFS is the only one of the three major wide-distributed file systems (AFS, WebNFS and CIFS) to support filenames in Unicode format. Unicode is a 16-Bit per character text format that supports all the many non-Latin alphabets that exist ing the world, such as Cryllic(Russian) and Kanji (Japanese). In a world spanning file system the ability to name files and other resources according to local languages and conventions is very important.

Examples of Use:

Since CIFS is supported by default in all Microsoft Operating Systems there is a huge user base connected to the Internet capable of using CIFS servers. Also the draft standard is supported by Linux, most Unix and by VMS. Java implementations also exist. Actual servers using the protocol are unfortunately difficult to locate by the very fact that servers rarely advertise their operating systems or file systems. However with the protocol being part of the most common operating system in the world and being supported by almost all others there are surely to be many examples of use in the future, if not today.

Overview:

Microsoft's Common Internet File System allows secure (through DES) distributed resource access over the Internet (by UDP or TCP) and gives several advantages over other competing systems. Extended File Attributes allow support to be added for almost any access requirement.File Locking support that is missing from most LAN based protocols. Unicode filename support allows international cooperation without forcing a U.S. centric worldview on those from other parts of the globe. Offering both Share and User level access allows flexibility in administering who should have access to the system's resources.

These features, plus the vast market penetration given by the Microsoft brand combined with it being an open standard supported by rival vendors ensures that CIFS should have a bright future.

References:

Previous Next

Return to Common File System Index