Network File System

from Wikipedia, the free encyclopedia
NFS in the OSI layer model
application NFS
presentation XDR
meeting (Sun) RPC
transport ( UDP ) TCP
network IP ( IPv4 , IPv6 )
Network access Ethernet Token
ring 		FDDI ...

The Network File System ( NFS , and Network File Service ) - is one of Sun Microsystems developed protocol that provides access to files over a network possible. The files are not processed like B. Transferred with FTP , but users can access files that are on a remote computer as if they were stored on their local hard drive .

In this Unix network protocol is an Internet - standard ( RFC 1094 , RFC 1813 , RFC 3530 , RFC 7530 ), also known as distributed file system ( english distributed file system ) is called.

The equivalent of NFS is called Server Message Block (SMB) in Windows and OS / 2 environments . While the user authenticates himself with SMB, the more popular NFSv3 authenticates the client computer; only NFSv4 enables user authentication. NFS services are also on Microsoft Windows - servers , making UNIX available workstations access can get their files, but SMB is in mixed environments usually with Samba used on Unix side.

NFS originally works on the IP network protocol together with the stateless UDP . But now there is also NFS over TCP . NFSv4 only works with TCP and only needs one port (2049), which facilitates operation through firewalls . NFSv4 was largely developed by the IETF after Sun gave up the development.

Schematic data transfer process

The following describes the basic sequence of NFS communication of the old stateless NFS up to and including version 3. Scenario: A user of the client computer wants to open a remote directory ( / directory ) and display a file ( test ) in it.

In order for data to be exchanged between the NFS server and client, the NFS server must be started and registered with the portmapper .

  1. Client contacted mapper on port 111 and ask for the Port of Mount - daemons (mountd)
  2. Portmapper outputs port number for mountd. Typically this is 694.
  3. Client contacts mountd and asks for a filehandle for / directory , the directory of the server to be mounted by the client.
  4. mountd returns a filehandle 0 as the root filehandle for the directory of the server to be mounted
  5. Client contacts Portmapper and asks for the port for NFS (nfsd). Typically this is 2049.
  6. Portmapper publishes port number for nfsd
  7. Client leads LOOKUP - procedure of the parameters file handle 0 and the file name ( test )
  8. nfsd issues filehandle 1 for file ( test )
  9. Client executes READ procedure with parameter Filehandle 1
  10. nfsd returns content of file ( test ) (data)

Design of the early versions of the system

A program accesses the file system via system calls . Under Unix the most important system calls are:

  • open , close - open and close a file
  • read , write - read and write
  • create , unlink - create and delete
  • mkdir , rmdir - create and delete a directory
  • readdir - read directory entries

A network file system has to pack these calls into network packets and send them to a server . This then responds with the appropriate information or an error.

The developers at Sun Microsystems initially opted for a remote procedure call model. XDR converts the parameters of the RPC into a machine-independent format, the accesses are then handled like a normal subroutine call via the RPC mechanism.

The system calls are not converted directly into RPC calls, since a file opened via open would then also have to be opened on the server. With many clients, the servers would quickly become overloaded because the machines still had relatively little memory in the mid-1980s. The tasks of the server have therefore been kept as simple as possible, the server does not remember any file information between two RPC calls. So he's stateless.

Instead of open , a lookup call is implemented. This provides a file “handle” that contains the inode number and the device number of the mass storage device on the server. This handle can be used to uniquely identify a file on the server. Under Unix, the file information is efficiently and clearly available via these two numbers without a time-consuming search.

The other calls such as read or write must always transfer an offset so that the server can clearly deliver the desired information without knowledge of previous operations.

Further properties of the protocol are

  • only short cache times (a few seconds) for directory information and file attributes
  • no data cache
  • Use of the connectionless User Datagram Protocol ( UDP ) optional TCP (NFSv4 only TCP)
  • Lock and mount operations using additional auxiliary protocols
  • Use of Unix file attributes ( e.g. user uid )

Because of its simple design, NFS runs well in normal environments:

  • local network with short response times
  • Running programs over the local network
  • Normal user activities (editing, translating programs)
  • Server with relatively little memory

The behavior at

  • file sharing
  • Use over the Internet (long response times, poor security)
  • Use of firewalls (UDP, no fixed port because of port mapper ) (No problem under NFSv4; all communication runs over port 2049 / TCP)

The protocol was developed in the late 1980s. Even expensive workstations only had a few Mebibytes of RAM at that time , typically around 4 to 8  MiB . An NFS server can still be operated efficiently on such machines due to its design.

Because of the stateless server, it can be shut down and restarted without data loss. Programs don't crash, and users simply have to wait for the server to become available again.

Hard disk-less work computers

Workstations (workstations) can be operated via NFS without hard disk. The operating system and the operating parameters can be loaded via protocols such as BOOTP and TFTP . A special kernel (e.g. Linux) can then already access the root drive under Unix via NFS. Special diskless workstation ( diskless workstations ) were offered by Sun in the 1990s.

The advantages are reduced maintenance costs, shared use of storage space, and simpler and less expensive client workstations ( thin clients ). With many clients, however, the server is heavily loaded, and access via the network is slower in most cases.

PC-NFS

Sun and other companies also offered NFS client software for PCs under Windows in the 1990s , the PC-NFS. The server still had to be a Unix workstation. Until Windows for Workgroups , network access was not part of the operating system under Windows. This made the use of PCs much easier in Unix environments.

PC-NFS had to struggle with the different concepts of the DOS / Windows system. The Windows versions of that time only allowed file names with up to eight characters and a three-character extension separated by a period (e.g. AUTOEXEC.BATthe so-called 8.3 notation), while Unix allowed path names of 255 characters. In contrast to DOS, the file names are case-sensitive. PC-NFS therefore had to translate between the file name concepts.

A Unix file name file.txt appeared as FILE.TXT under Windows / DOS, while a file name Documentation.txt was converted into DOKUME ~ 1.TXT , for example .

NFS version 4

NFS Version 4 is a new implementation that takes newer requirements into account. It is standardized in RFC 7530 .

The Unix burden of the early versions is reduced as much as possible. The UNIX user and group numbers are replaced by more unambiguous strings based on the pattern user @ domain. user is the user name on the server, domain is the domain of the server, i.e. the part of the host name that does not identify the server itself ( srv.cs.example.net → cs.example.net ). With the identifier user@cs.example.net , the user can now be clearly identified on all computers in the domain cs.example.net , even if the user user on the server has the Unix user ID 1050 and on the client z. B. 1100. This led to problems with earlier NFS versions if consistent user numbering was not adhered to. For the implementation of the new NFS username in (Unix) user IDs on Linux, for example, the service rpc.idmapd ( ID map by d aemon ), under FreeBSD the daemon nfsuserd ( NFS user d aemon charge) (for servers - as well as for the client side). The usernames are only correctly assigned if the server and client have the same domain, otherwise nobody.nogroup is specified as the owner .

Since some file systems do not allow for an efficient implementation of unique file handles , volatile handles are introduced that are only available for a certain period of time. Under Unix, handles can be constructed very easily from the device and inode number. Case-insensitive file systems and custom file attributes are now also supported.

The mount and lock protocol are now part of the protocol itself, auxiliary protocols are no longer required. The protocol itself runs on the fixed TCP port 2049 , UDP is no longer supported. Earlier versions ran on this port, but the RPC portmapper assigned the auxiliary protocols dynamically. The use of firewalls for NFS connections is greatly simplified by these measures.

Several requests can be bundled ( combined request ), they are then carried out by the server and only one response has to be sent back. The protocol can therefore also be used efficiently in the wide area area ( WAN ), for example between different locations of an organization.

The lookup call is replaced by open , which enables file information to be saved . For example, the read / write position could be managed on the server. File sharing is also better supported. If many clients read a file only, it can be awarded to all clients ( leases are). If a client wants to write a file, it can be lent exclusively.

In version 4.1, among other things, parallel access to storage distributed over several servers has been added. From version 4.2 in November 2016, server-side copies and sparse files are supported.

Configuration in Unix systems

Under Unix, the NFS shares are usually specified on the server side in the / etc / exports file, which is structured according to the following scheme. Note the differences between Linux and FreeBSD systems: 

# Server-Adresse: 10.0.0.1
# NFSv2, NFSv3:
# Exportiert /path/to/directory an alle IPs von 10.0.0.0 bis 10.0.255.255,
# und zwar zum Lesen/Schreiben (rw), asynchronem Zugriff (Daten werden
# nicht sofort geschrieben) und auch von Ports über 1024 aus (insecure)
#
# Erreichbar als: 10.0.0.1:/path/to/directory
#
### Linux-Systeme
/path/to/directory        10.0.0.0/16(rw,async,insecure)

### FreeBSD
/path/to/directory        -network 10.0.0.0/16

# NFSv4:
# Benötigt zur optimalen Funktion eine Freigabe mit der Option fsid=0.
# Diese wird als root-Freigabe genutzt und ist als die Freigabe / zu
# erreichen. Die anderen Freigaben liegen unterhalb davon. Ansonsten
# ist optional eine Authentifizierung/Verschlüsselung mit Kerberos
# möglich.
#
### Linux-Systeme:
# Erreichbar als 10.0.0.1:/
# Wird diese Freigabe eingehängt, so sind alle darunterliegenden
# Freigaben logischerweise zugänglich.
/path/to/nfsv4/root       10.0.0.0/16(rw,async,insecure,fsid=0)
# Erreichbar als 10.0.0.1:/export1
/path/to/nfsv4/root/export1 10.0.0.0/16(rw,async,insecure)

### FreeBSD
# Root-Punkt spezifizieren (unter Linux der mit fsid=0 markierte Punkt)
V4: /path/to/nfsv4/root    -network 10.0.0.0/16
# Freigaben angeben
/path/to/nfsv4/root/export1 -network 10.0.0.0/16

The client can manually mount a share or, if necessary, automate it with an entry in the fstab file .

Many current Linux distributions come with graphical tools to simplify the integration of NFS shares into the system, for example the NFS- YaST plug-in under openSUSE .

safety

NFS version 3 and earlier

NFS was created to make file systems accessible across computer boundaries in Unix networks . At the time NFS was developed, such networks were almost exclusively managed centrally and the computers were administered centrally, and the security concept was designed accordingly.

The developers of NFS at Sun Microsystems originally intended to implement security as the role of the RPC layer. For this purpose, RPC is replaced by Secure-RPC. The NFS protocols themselves remain unaffected. Secure-RPC, however, has not found widespread use, nor is it possible to use it in all implementations.

An NFS server with no secure RPC exported file systems to certain other computer (from root by IP addresses specified) d. H. the root user of a client computer can access all files that the server exports to the client, regardless of their access rights. The access rights (of the user) are also transferred by NFS to the client and evaluated by the operating system of the respective computer and enforced against the users. The consistency of the user database on the computers involved is z. B. achieved through NIS .

Today computer networks are often open and only to a limited extent centrally administered. H. an attacker can relatively easily either take over a computer that the NFS server trusts, e.g. B. reboot with a live system or add an additional laptop to the network and accept the IP of an NFS client that is not currently running. In both cases, since the attacker has root rights on his system, he can access all files exported to the client, regardless of their access rights. NFS v3 is therefore only as secure as the network and the computers involved without a separately installed Kerberos .

The above-mentioned scenario can be prevented with the server option root_squash (under FreeBSD with the option -maproot = <USER> to be specified in the corresponding line ). This means that accesses by users with UID 0 (usually root ) are treated as accesses by the anonymous user (UID = 65534), who then May not have any access rights to the shared files. An attacker now has to try different UIDs when connecting until he catches the UID of the user or group that is authorized. Since there are only (65536) UIDs, this approach does not offer any real security either.

NFS version 4

NFSv4 solves this problem by e.g. B. Kerberos is now an integral part of the protocol and enables user identification.

Norms and standards

Version 1.0 was created by Sun Microsystems in 1984. From version 2.0, further standardization took place as a request for comments . It was not until version 4.0 that the status informational changed to the official standard. The three versions 4.0, 4.1 and 4.2 are all current standards, which is why there have been additions without a version number since 2017:

a) Original path from version 2 to version 4.0:

  • RFC 1094 NFS Version 2 Protocol Specification (1989, obsolete by RFC 3010 )
  • RFC 1813 NFS Version 3 Protocol Specification (1995, obsolete by RFC 3010 )
  • RFC 3010 NFS Version 4 Protocol (2000, deprecated by RFC 3530 )
  • RFC 3530 Network File System (NFS) version 4 Protocol (2003, deprecated by RFC 7530 )
  • RFC 7530 NFS Version 4 Protocol Specification (2015)
  • RFC 7931 NFSv4.0 Migration: Specification Update (2016)

b) Newer versions 4.x

  • RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol (NFS 4.1, 2010)
  • RFC 7862 Network File System (NFS) Version 4 Minor Version 2 Protocol (NFS 4.2, 2016)

c) Additions for 4.x

  • RFC 8178 Rules for NFSv4 Extensions and Minor Versions (2017)
  • RFC 8434 Requirements for Parallel NFS (pNFS) Layout Types (2018)

Web links

Individual evidence

  1. ^ Design and Implementation of the Sun Network Filesystem . USENIX . 1985.