Network File System

Network File System (Network File System), or NFS, is a network layer protocol. application, according to the OSI Model. It is used for distributed file systems in a local area computer network environment. It enables different systems connected to the same network to access remote files as if they were local ones. It was originally developed in 1984 by Sun Microsystems, with the aim of making it independent of the machine, the operating system and the transport protocol, this was possible thanks to the fact that it is implemented on top of the XDR (presentation) and ONC RPC (session) protocols.. The NFS protocol is included by default in UNIX Operating Systems and most Linux distributions.

• The NFS system is divided into at least two main parts: a server and one or more customers. Customers remotely access the data stored on the server.

• Local workstations use less disk space because the data is centralized in a single place but can be accessed and modified by several users, so that it is not necessary to replicate the information.

• Users do not need to have a “home” directory on each machine in the organization. The “home” directories can be created on the NFS server to later access them from any machine through the network infrastructure.

• Storage devices such as floppy disks, CD-ROMs and ZIP units can also be shared through the network. This can reduce investment in such devices and improve the use of existing hardware in the organization.

All operations on files are synchronous. This means that the operation only returns when the server has completed all the work associated with that operation. In the event of a write request, the server will physically write the data to disk, and if necessary update the directory structure, before returning a response to the client. This guarantees the integrity of the files.

Architecture

Suppose a network file system (NFS) client tries to mount a directory taken from the NFS server to a local directory. To do this, you will need the following command:

$ mount -t nfs maquina_remota:/home /dir_local

In this command we specify the type of file system to be mounted with –t, the remote machine and the directory where we are going to mount it.

This command tries to connect to the rpc mountd daemon running on the remote machine via RPC. The server checks the client's permissions on the /home directory where it is going to be mounted and if it has them, it is mounted as if it were any other physical device. Once the mount is done, when you access the client directory you will be accessing the remote server directory.

When the directory /local_dir already has the /home directory of the remote machine mounted, the only protection that the files in that directory have are their permissions.

Accessing the files in the NFS directory will generate an RPC call to the rpc nfsd daemon on the server, which includes the parameters corresponding to the user's UID and GID and the user's descriptor. file, against which the permissions will be checked.

Typical Implementation

Assuming a Unix-style scenario where one machine (the client) needs to access data stored on another machine (the NFS server):

• The server implements NFS daemon processes, which are run by default as nfsd, so that your data are generically available to customers.
• The server administrator determines what to make available, exporting the names and parameters of the directories, usually using the configuration file / etc / exports and the exportfs command.
• The server security management ensures that you can recognize and approve validated customers.
• The server network configuration ensures that appropriate customers can negotiate with it through any firewall system.
• The customer's team requests access to the exported data, usually issuing an assembly command. The client asks the server (rpcbind) which port is using the NFS server, the client connects to the NFS server (nfsd), nfsd passes the application to mountd.
• If all goes well, customer machine users can view and interact with file systems mounted on the server within the allowed parameters.
• Note that the automation of the NFS assembly process can take place, perhaps using / etc / fstab and/or assembly facilities.

This file system is used so that in a local network different computers can access files and share them, in this way, a computer can access the information of another computer as if it were a hard drive. NFS focuses on consistency, assuming heavy writes that probably won't happen very often.

One of the main uses of the NFS protocol is to be able to have all the files centralized on a single server. This will make it possible to do without memory units in other computers and to be able to enter remotely to read any file or download it.

It is very useful especially when there are many users who are going to have to log in to modify those files

Advantages

• Multiple clients can access the files
• Reduces the need to have disk space
• Any user can modify and update the files
• Compatibility with many teams

Disadvantages

• Security: Just use it on secure networks and behind a firewall
• Requires a big overload to read files
• It is not easy to block files or give permissions

NFS Client

The client simulates the functionality of the UNIX file system, built directly into the kernel. It is in charge of controlling the VFS requests to the server. Send the blocks or files from the server and to the server. When possible, cache the blocks locally.

Cache memory

The NFS client module caches the results of <readwritegetattlookup> and readdir. Clients are responsible for polling the server to check the freshness of their cache data.

Timestamp method to maintain caches:

Each element is tagged with two different times, one the last time the element was validated and the other the last time it was modified on the server. A cached entry is valid at time t if t-time last validated is less than the tolerated refresh interval. If the input is not valid, the time at which it was last modified on the server is obtained and if it is equal to that of the client, then the input is valid and the time of the client is updated, otherwise the input is invalid.

To minimize getattr calls, when a value is received from the server for a file, it is applied to all relevant entries in that file.

Even with this there will be consistency issues if we have writes on two clients with a time difference less than the tolerated refresh interval. To solve this problem we will have to use file locking converting the file into a critical section, this is achieved in NFS through the Network Lock Manager (NLM) protocol.

NFS Server

The NFS server is part of the Linux kernel, in the kernels that Debian provides it is compiled as a kernel module. Its interface is defined in RFC 1813.

It is responsible for receiving requests, which can be similar to those of the flat file model or can simulate those of the UNIX system.

The server also offers mounting services, authentication and access control, and a cache.

Cache memory

There are two options to maintain and ensure write consistency:

• write-through: the data of writing operations are stored in cache and written on disk before responding to the customer.
• Commit: the data of writing operations are saved only in cache. They only write to disk when a commit operation is received.

The essential daemons of the NFS service are the following:

• rpc.mountd: Demon that handles remote assembly. Receive the request from the NFS client and check that the file system is exported and if available it allows NFS access requests and provides information on it (show).
• rpc.nfsd: Demon to serve files. Several copies of this demon may be removed. Use the TCP/UDP 2049 port.
• rpc.portmap: It is responsible for indicating to customers where the actual service is located on the server. RPC-based services use portmap to meet customer requests so this service should be available first. It is not used in NFSv4. To verify that it is active to execute:
  • $ sudo portmap status
• rpc.lockd: responsible for providing the file lock service to ensure consistency as they can be accessed concurrently. It runs on both the server and the client.
• rpc.statd: This demon works together with lockd to recover in system crash. Keeps information about processes in customers who own file locks of a particular server. When the NFS server recovers statd informs the other customers that the server has recovered and so they solve the locks they had.

Security

If we want our NFS service to be more secure, we should take into account a series of details, such as:

1. Use the wilds (metacharacters) as little as possible, as we can access more equipment than we are thinking about.
2. Use Iptables rules (firewalls) to limit access to ports used by NFS service demons.
3. The use of /etc/hosts.allow and /etc/hosts.deny files is not mandatory but it is preferable to configure them to ensure data security.
4. Export reading file systems (ro) whenever possible.
5. The owner of the exported files and directories that is root since it is possible to map the root UID to the user nobody.
6. Try that exported files do not have writing permission for the group (ACL).
7. NFS 2 and 3 versions do not have access control for specific users. In them, when a file system is exported, any user on any remote machine connected to the NFS server can access shared data. The only security mechanism they have is to use read-only access and reduce all users to a common one whose UID and GID we specify.
8. If the squash export option is not used, any root user in the client computer can become a privileged user simply by running the order: your -. It is always appropriate to have activated some option squash.
9. The safest version of NFS is 4.

NFS includes the user's identity by default in requests to the server, but only to compare it with access permissions, it does not validate it.

With kerberos, user authentication is performed at file system mount time. The results of these authentications are stored and used on each NFS request. This protects against most attacks.

NFS Versions

The major versions of NFS are NFSv2 (RFC 1094), NFSv3 (RFC 1813), and NFSv4 (RFC 3530).

NFS version 2 is the most widely used and supported by operating systems, as well as the oldest and most insecure. Version 3 is more powerful than version 2 but is not fully compatible with previous version clients. These two versions can work with both TCP and UDP as the transport protocol creating network connections between client and server. The advantage of using UDP is that network traffic is minimized, but if it were to go down, the clients would continue sending messages and it would be saturated.

In general, NFS versions 2 and 3 allow you to control the export and mounting of file systems based on the requesting machine, but not on the user. In other words, access control to the file system by user is not contemplated. For teams only. This implies that if a file system is exported from the NFS server, any user on a remote NFS client machine could access it. The only remaining security mechanisms in this case are access permissions (read only) or using a user and group only. Logically this greatly limits the idea of sharing that we all have.

In the case of version 4 of NFS these security problems disappear but, in return, it has much more important configuration requirements and additional services. For example, in version 4 the use of mechanisms for user authentication is mandatory. For this and depending on the type of security selected, the use of the Kerberos service is required, whose mission will be to function as a ticket delivery server (KDC) and which must be configured and working correctly before configuring the NFSv4 server. This requirement provides security to the NFS service in exchange for including more complexity in its configuration and tuning.

Another important feature of NFS4 is the use of Windows-style ACLs (Access Control Lists) that are not supported by NFS versions 2 and 3. When we talk about ACLs, we are referring to the permissions or access rights that each user has over a file or directory and that are specified as editable lists by the system administrator.

NFS Advantages

• They reduce the risk that the failure of a single team prevents access to data.
• They provide centralized locations for data that should or should be shared among all users.
• They simplify access to existing data in faster systems.
• They provide the opportunity to centralize administrative operations, such as data backup (back-ups).
• They provide interoperability and flexibility. Network file systems can normally be accessed from computers running Linux, Windows, Mac OS X, BeOS, BSD, and many others. In this way it is easy to use the hardware and software best suited to desktop requirements, and still access the same data from the network file system environment.

NFS Disadvantages

• NFSv2 and NFSv3 can use UDP as a transport protocol that, being a neglected connection, minimizes network traffic, but if the NFS server fell by any circumstance, NFS clients would continue to send requests to the server producing the opposite effect, which is the saturation of the network.
• NFS 2 and 3 versions allow to control the export and assembly of file systems according to the equipment that makes the request, but not the user. That is not to say a control of access to the file system by user. Just for the teams. This means that if a file system is exported from the NFS server, any user of a remote NFS client computer could access it.
• NFS suffers some performance problems due to its “stateless” design (part of these problems are mitigated in the latest versions of NFS). In particular, as the client assumes that a writing operation is completed once it receives the server's acknowledgement, the server must make sure to write each block to disk before responding, to avoid discrepancies in the case of a fall. This introduces a significant delay in the case of NFS writings.

Operations

Initially NFS supported 18 procedures for all basic I/O operations. The protocol version 2 commands are as follows:

• NULL: it does nothing, but it serves to ping the server and measure times.
• CREATE: creates a new file.
• LOOKUP: finds a file in the current directory and if you find it, returns a descriptor to that file more information about the attributes of the file.
• READ and WRITE: basic primitives to access the file.
• RENAME: renames a file.
• REMOVE: deletes a file.
• MKDIR and RMDIR: creation/boarding of subdirectories.
• READDIR: to read the directory list.
• GETATTR and SETATTR: returns set of file attributes.
• LINK: creates a file, which is a link to a file in a directory, specified.
• SYMLINK and READLINK: for the creation and reading, respectively, of symbolic links (in a "string") to a file in a directory.
• STATFS: returns information from the file system.
• ROOTto go to the root (obsolete in version 2).
• WRITECACHE: reserved for future use.

In version 3 of the protocol, the STATFS, ROOT and WRITECACHE commands are removed; and added the following:

• ACCESS: To verify access permits.
• MKNOD: Create a special device.
• READDIRPLUS: an improved version of READDIR.
• FSSTAT: returns information from the file system dynamically.
• FSINFO: returns information from the file system statically.
• PATHCONF: Recover POSIX information.
• COMMIT: Send cache data on a server a stable storage system.

Version 4 was released in April 2003 and is not backward compatible. Supports 41 commands: NULL, COMPOUND, ACCESS, CLOSE, COMMIT, CREATE, DELEGPURGE, DELEGRETURN, GETATTR, GETFH, LINK, LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, PUTPUBFH, PUTROOTFH, READ, READDIR, READLINK, REMOVE, RENAME, RENEW, RESTOREFH, SAVEFH, SECINFO, SETATTR, SETCLIENTID, SETCLIENTID_CONFIRM, VERIFY, WRITE, RELEASE_LOCKOWNER, ILLEGAL.