Network File System
The Network File System - abbreviated NFS ( Network File Service also ) - has been developed by Sun Microsystems protocol that allows you to access files over a network. The files are not transferred as eg FTP, but the user can access files that are located 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 ), which is also known as a distributed file system (english distributed file system).
The correspondence to NFS is, under Windows and OS/2-Umgebungen Server Message Block (SMB). While authenticates SMB users, the more popular NFS V3 authenticates the client machine, only NFS V4 allows user authentication. NFS services are also available on Microsoft Windows servers, UNIX workstations, which are able to access their files, but is mostly used in mixed environments with SMB Samba on Unix side.
NFS works on the IP network protocol originally together with the stateless UDP. Meanwhile, there are also NFS over TCP. NFSv4 uses TCP and only requires one port, which facilitates the operation through firewalls. NFSv4 has been largely developed by the IETF, after Sun had given the development.
Schematic flow of data transmission
Following is the basic procedure for an NFS communication of the old stateless NFS is described up to and including version 3. Scenario: A user of the client computer wants to open a remote directory ( / directory ) and leave therein a file (test) show.
This allows data exchange between NFS server and client can take place, the NFS server must be started and be registered with the portmapper.
Design of the early versions of the system
A program accesses the file system via system calls. In UNIX, are the most important system calls:
- Open, close - opening and closing a file
- Read, write - reading and writing
- Create, unlink - creating and deleting
- Mkdir, rmdir - creating and deleting a directory
- Readdir - read directory entries
A network file system has to pack these calls in network packets and send them to a server. Then responds with the appropriate information, or an error.
The developers of Sun Microsystems initially opted for a remote procedure call model. XDR sets the parameters of the RPCs are in a machine-independent format, the accesses are then treated via the RPC mechanism as a normal subroutine call.
The system calls are implemented but not directly in RPC calls since then would have to be opened on the server via open opened file. For many clients, the server would then be overloaded quickly since the middle of the machine of the 1980s still had relatively little memory. The tasks of the server were therefore kept as simple as possible, the server remembers no file information between two RPC calls. So he is stateless.
Instead open a lookup call is implemented. This provides a file " handle" that contains the inode number and the device number of the mass memory on the server. About this handle can be a file on the server to be uniquely identified. Under Unix is about these two numbers, the file information efficiently without consuming search clearly available.
The other calls, such as read or write must always pass an offset so that the server can provide the required information clearly here without knowledge of previous surgery.
Other features of the protocol are
- Only short cache time (a few seconds ) for directory information and file attributes
- No data cache
- Utilizing the connectionless User Datagram Protocol (UDP NFSv4 uses TCP )
- Lock and mount operations through additional auxiliary protocols
- Using Unix file attributes ( such as user - uid)
Because of the simple design, NFS is running well in normal environments:
- Local network with short response times
- Execute programs on the local network
- Normal user activities ( editing, translating programs )
- Server with relatively little memory
Less good is the behavior at
- Sharing of files
- Using via the Internet ( long response times, low security )
- Use of firewalls (UDP, no fixed port because portmapper ) (Below NFSv4 no longer a problem; any communication is done via port 2049/TCP )
The protocol was developed in the late 1980s. And expensive workstations had at this time only a few megabytes of memory, typically approximately 4 to 8 MB. An NFS server can be run on such machines, because of the design still efficient.
Because of the stateless server, it can be shut down without data loss and restarted. Programs do not crash and users simply have to wait until the server is available again.
Diskless workstations
Workstations (workstations ) can be operated via NFS without hard drive. The operating system and the operating parameters may be loaded via protocols such as BOOTP and TFTP. A special kernel (eg Linux) can already access via NFS on the root drive on Unix. Special diskless workstations ( diskless workstations ) were offered by Sun in the 1990s.
Advantages include reduced maintenance costs, sharing of space as well as simpler and inexpensive client workstations ( thin clients ). In many clients, the server is heavily loaded, however, also the number of hits over the network in most cases is slow.
PC-NFS
Sun and other companies offered in the 1990s also NFS client software for PCs under Windows, the PC - NFS. The server had to continue to be a Unix workstation. Until Windows for Workgroups network access was not part of the operating system under Windows. In Unix environments, the use of computers greatly facilitated.
PC-NFS had to fight with the different concepts of DOS / Windows system. The former Windows versions allowed only file names up to eight characters and a three -character extension, which was separated by a dot (eg, AUTOEXEC.BAT, the so-called 8.3 - notation ), while Unix allowed 255 characters long path names. The file names distinguished in contrast to DOS is case- sensitive. PC-NFS so had to translate between the filename concepts.
A Unix file name appeared file.txt as FILE.TXT under Windows / DOS while a file name Dokumentation.txt 1.TXT was implemented in about DOCUME ~.
NFS Version 4
The NFS version 4 is a new implementation that takes into account newer requirements. It is standardized in RFC 3530.
The Unix burdensomeness of the early versions is reduced as far as possible. The UNIX user and group numbers will be replaced by clearer strings according to the pattern user @ domain. user here is the username on the server, domain is the domain of the server, ie the part of the host name, not the server itself identified ( srv.cs.example.net → cs.example.net ). Through the identification of the domain [email protected] cs.example.net the user can now be clearly identified on all computers, even if the user user on the server, the Unix user ID is 1050 and on the client, for example, 1100th This resulted in earlier versions of NFS problems when no consistent users numbering was respected. For the implementation of the new NFS user name ( Unix ) user IDs on Linux, for example, the service rpc.idmapd (ID mapper daemon), under FreeBSD daemon nfsuserd (NFS daemon user ) responsibility (for both server and for client side). The user names are mapped correctly only if the server and client have the same domain, otherwise is specified as the owner nobody.nogroup.
Since some file systems do not allow efficient implementation of unique file handles, volatile handles are introduced that are only a limited amount of time. On Unix, you can handle very easily construct from the device and inode number. Even file systems that are not case -sensitive and user-defined file attributes are now supported.
The mount and Lockprotokoll are now part of the protocol itself, Auxiliary protocols are no longer needed. The protocol itself runs on the fixed TCP port 2049, UDP is no longer supported. Although even earlier versions ran on this port, the auxiliary protocols but were allocated by the RPC portmapper dynamically. The use of firewalls with NFS connections is greatly simplified by these measures.
Multiple requests can be bundled ( combined request ), they are executed by the server and only one response must be returned. The protocol can be so efficient in wide area networks (WAN ) are used, for example, between different locations of an organization.
Encryption is now part of the specification. Although encryption was previously already possible through Secure -RPC. This was rarely used, among other things, because Secure - RPC does not everywhere was available.
The lookup call is replaced by open, the storage of file information is made possible. For example, the write position could be maintained on the server. Also, the sharing of files is better supported. If many clients read a file only, this can be awarded to all clients ( leases ). When a client wants to write a file, it can be awarded exclusive.
Configuration in Unix systems
The NFS shares are on the server side usually set under Unix in the / etc / exports file that is structured according to the following scheme. The differences between (for example ) are to be observed Linux and FreeBSD systems:
# Server address: 10.0.0.1 # NFSv2, NFSv3: # Exports / path / to / directory to all IPs from 10.0.0.0 to 10.0.255.255, Be # namely for read / write (rw ), asynchronous access (data # Posted immediately ) and also from ports above 1024 from ( insecure ) # # Accessible as: 10.0.0.1 :/ path / to / directory # # # # Linux systems / path / to / directory 10.0.0.0/16 (rw async, insecure ) # # # FreeBSD / path / to / directory -network 10.0.0.0/16 # NFSv4: # Requires a release for optimal function with the option fsid = 0 # This is used as a root - released and is available as the release / to # Reach. The other shares are below it. otherwise # Is optional authentication / encryption using Kerberos # Possible. # # # # Linux systems: # Accessible as 10.0.0.1 :/ # If hooked this release, then all underlying # List the shares logically accessible. / path/to/nfsv4/root 10.0.0.0/16 (rw, async, insecure, fsid = 0) # Accessible as 10.0.0.1 :/ export1 / path/to/nfsv4/root/export1 10.0.0.0/16 (rw async, insecure ) # # # FreeBSD # Root point specify (under Linux the marked with fsid = 0 point) V4: / path/to/nfsv4/root -network 10.0.0.0/16 # Specify clearances / path/to/nfsv4/root/export1 -network 10.0.0.0/16 The client can mount a share manually or optionally automate fstab with an entry in the file.
Many current Linux distributions are available in graphical support tools to facilitate the integration of NFS shares into the system, such as the YaST NFS plugin under openSuse.
Security
NFS was created to do in Unix networks file systems across computer boundaries accessible. At the time of development of NFS such networks were almost exclusively managed centrally and the computers were centrally administered, the security concept has been designed accordingly.
The developers of NFS, Sun Microsystems had originally planned to implement security as a task of the RPC layer. These RPC is replaced by Secure -RPC. The NFS protocols themselves are unaffected. Secure RPC, however, has not been widely distributed, its use is not at all possible implementations.
An NFS server with no secure RPC exported file systems on some other computer ( from the root with IP addresses defined ), that is, the root user on a client computer can access all the files that are exported from the server to the client, regardless of their access rights. The access rights (the user ) are also transmitted by NFS to the client and evaluated by the operating system of each computer and enforced against the users. The consistency of the user database on the computers involved is achieved by NIS, for example.
Today, computer networks are often open and only partially administered centrally, that is, an attacker can relatively easily either use a calculator, which the NFS server trusts by new with a live system boots it, for example, or an additional laptop depends on the net and takes the IP of a not currently running NFS clients. In both cases, the attacker because he has root privileges on their system, access all files exported to the client, regardless of their access rights. Thus NFS v3 is installed separately without Kerberos only as secure as the network and the computers involved.
With the server options root_squash ( under FreeBSD with the particulars to be provided in the appropriate line - maproot option =
NFSv4 solves this problem by, for example, Kerberos is now an integral part of the protocol and a user identification possible.
Specifications
- RFC 1094 (NFS Version 2 Protocol Specification )
- RFC 1813 ( NFS Version 3 Protocol Specification )
- RFC 3530 (NFS version 4 Protocol Specification )