The Network File System Chapter 17

Chapter 17 -The Network File System Introduction The Network File System, commonly known as NFS, allows you to share filesystems among computers. NFS is almost transparent to users and is “stateless,” meaning that no information is lost when the NFS server crashes. Clients can simply wait until the server returns and then continue as if nothing happened. Chapter 17 -The Network File System

Chapter 17 -The Network File System Introduction NFS was introduced by Sun Microsystems in 1985. It was originally implemented as a surrogate filesystem for diskless clients. The protocol proved to be well designed and very useful as a general file-sharing solution. All UNIX vendors provide a version of NFS many use code licensed from Sun Chapter 17 -The Network File System

1. General Information about NFS Introduction: NFS consists of a number of components including: a mounting protocol mount server, daemons that coordinate basic file service server diagnostic utilities Chapter 17 -The Network File System

1. General Information about NFS NFS Protocol Versions The NFS protocol has been remarkably stable over time. The original public release of NFS was version2. Version 3 came out in the early 1990s (a collection of changes to increase performance and provide better support for large files. Chapter 17 -The Network File System

1. General Information about NFS Choice of transport NFS runs on top of Sun’s RPC (Remote Procedure call) protocol, which defines a system-independent way for processes to communicate over a network. Therefore it is possible to use UDP or TCP NFS and UDP do not do congestion control. (the original setup) Most systems now allow you to use TCP as the transport for NFS instead of UDP Chapter 17 -The Network File System

1. General Information about NFS Choice of transport (cont) Table 17.1 pg 490 Chapter 17 -The Network File System

1. General Information about NFS File locking File locking (as provided by flock and/or lock system calls) has been a sore point on UNIX systems for a long time. On local filesystems it has been known to work less than perfectly. In the context of NFS the ground is shakier still. Since the NFS servers are stateless they have no idea which machines (or processes) are using a given file, But this is needed for locking…..so, what to do? Chapter 17 -The Network File System

1. General Information about NFS File locking (cont.) The traditional answer has been to implement file locking separately from NFS Most systems provide two daemons, lockd and statd, that try to make a go of it. Unfortunately, the task is difficult for a variety of subtle reasons and NFS file locking has generally tended to be flaky. Chapter 17 -The Network File System

1. General Information about NFS Disk quotas Access to remote disk quota information can be provided by a similar out-of-band server, rquotad. An NFS server will enforce disk quotas, but servers cannot view their quota information unless rquotad is running on the remote server. Chapter 17 -The Network File System

1. General Information about NFS Global UIDs and GIDs UNIX identifies users and groups by number. If machine X shares files with machine Y, then UID 644 had better refer to the same user on both systems or a serious security or privacy problem could result. NFS servers need not allow remote users to log in. Chapter 17 -The Network File System

1. General Information about NFS Root access and the nobody account While users should be given identical privileges wherever they go, it’s traditional to prevent root from running rampant on NFS-mounted filesystems. By default, NFS servers intercept incoming requests made on behalf of UID o and change them to look as if they are coming from some other user. Remember, root on an NFS client can su to whatever UID it desires, so user files are never really protected. Chapter 17 -The Network File System

1. General Information about NFS Cookies and stateless mounting A client must explicitly mount an NFS filesystem before using it. However, because NFS is stateless, the server does not keep track of which clients have mounted each filesytem. Instead the server gives a “cookie” upon a successful mount and that cookie identifies the mounted directory to the NFS server Cookies persist across NFS server reboots (unless they went to single-user mode and then back up) Chapter 17 -The Network File System

1. General Information about NFS Security and NFS NFS provides a convenient way to access files on a network, and thus it has great potential to cause security problems In may ways NFS is a poster child for everything that is or ever has been wrong with UNIX security. The NFS protocol was originally designed with essentially no concern for security. Authentication modules were later allowed (but not required) in the RPC protocol. Sun’s public key and Kerberos Chapter 17 -The Network File System

1. General Information about NFS Security and NFS (cont.) The greatest risk is presented by on-site machines that are legally allowed to mount a filesytem. If anyone that you don’t fully trust (that means they are breathing still) has root access on a client host, don’t export any filesystems to that host. If your site has a firewall, it is a good idea to block access to TCP and UDP ports 2049 (used by NFS) and 111 (used by SunRPC portmap daemon) Chapter 17 -The Network File System

Chapter 17 -The Network File System 2. Server-side NFS Introduction: A server is usually said to “export” a directory when it makes the directory available for use by other machines. Solaris uses the word “share” The process used by clients to mount a filesystem (get the cookie) is completely separate from the process used to access files. Separate protocols and separate daemons mountd and nfsd sometimes called rpc.nfsd and rpc.mountd Chapter 17 -The Network File System

Chapter 17 -The Network File System 2. Server-side NFS Introduction: (cont) On an NFS server, both mountd and nfsd should start when the system boots. They share a single access control database which filesystems should be exported and which clients may mount them. Kept in xtab or sharetab You use eportfs to update these files Most systems have a human readable file that is used (at boot time) to create xtab - this file is usually /etc/exports Chapter 17 -The Network File System

Chapter 17 -The Network File System 2. Server-side NFS Introduction: (cont) FreeBSD consults this file (/etc/exports) directly after modifying this file you must send mountd a HUP signal to tell it to read the file’s contents again. kill -HUP `cat /var/run/mountd.pid` Table 17.2 pg 494 Chapter 17 -The Network File System

Chapter 17 -The Network File System 2. Server-side NFS Introduction: (cont) NFS deals with the logical layer of the filesystem. Any directory can be exported But sub mounted systems will not go with it. Clients are allowed to mount subdirectories of an exported system if they wish. If /users is exported to them, they can mount /users/joe and ignore the rest. Chapter 17 -The Network File System

Chapter 17 -The Network File System 2. Server-side NFS The exportfs command and the exports file (H-UX, Red Hat, FreeBSD) The exports file conssts of a list of exported directories in the leftmost column, followed by lists of associated options and attributes Example: /chimchim/users -access=band:moon,root=band /usr/share/man -access=xorasaurus:rastadon:moon,ro Chapter 17 -The Network File System

Chapter 17 -The Network File System 2. Server-side NFS The exportfs command and the exports file (H-UX, Red Hat, FreeBSD) (cont) Filesystems that are listed in the exports file without a specific set of hsots are usually mountable by all machines This is a sizeable security hole. Some NFS implementation limit lines in the exports file to 1,024 characters. That limit can come awfully fast, especially when you’re using fully qualified domain names Chapter 17 -The Network File System

Chapter 17 -The Network File System 2. Server-side NFS nfsd: serve files Once a client’s mount request has been validated by mountd, it can request carious filesystem operations. These requests are handled on the server side by nfsd, the NFS operations daemon. Chapter 17 -The Network File System

Chapter 17 -The Network File System 2. Server-side NFS nfsd: serve files nfsd takes a numeric argument that specifies the number of copies of itself that it should fork. Selecting the appropriate number is important and unfortunately something of a black art. Too high or too low and NFS performance suffers. There is no reason to run more than a few nfsd’s per spindle. You can watch the load (goes up if too many) and UDP packets dropped (with netstat -s) for too few. Chapter 17 -The Network File System

Chapter 17 -The Network File System 3. Client-side NFS Introduction mount understand the notation hostname:directory to mean the path directory interpreted by hostname On most systems, the optional but highly recommended daemon biod (block I/O daemon, sometimes called nfsiod) provides performance enhancements. Chapter 17 -The Network File System

Chapter 17 -The Network File System 3. Client-side NFS biod and nfsiod: provide client-side caching The provide read-ahead and write-behind filesystem block caching. We suggest that you run it on NFS clients that provide it, but that is not strictly required. The presence or absence does not affect administration. This daemon can also have multiple copies running On a garden variety machine 4 or 8 should be plenty. Chapter 17 -The Network File System

Chapter 17 -The Network File System 3. Client-side NFS Mounting remote filesystems You can use the mount command to establish temporary network mounts. You should list mounts that are part of a system’s permanent configuration in /etc/fstab so that they are automatically mounted at boot time. Or you can use an automounter like automount or amd NFS partitions can be unmounted with the umount command Chapter 17 -The Network File System

Chapter 17 -The Network File System 3. Client-side NFS Mounting remote filesystems (cont) Table 17.9 g 502 Chapter 17 -The Network File System

Chapter 17 -The Network File System 3. Client-side NFS Secure port restrictions NFS clients are free to use any TCP or UDP port they like. However, some servers may insist that the requests come from a privileged port (<1024) In the world of PCs and desktop UNIX boxes, the use of a privileged port provides little actual security. Chapter 17 -The Network File System

4: NFSSTAT: Dump NFS Statistics Most systems provide a command called nfsstat that can display various statistics kept by the NFS system. nfsstat -s show stats for the server nfsstat -c shows stats for the client Running nfsstat occasionally and becoming familiar with its output will help you discover NFS problems before your users do. Chapter 17 -The Network File System

5. Dedicated NFS File Servers Fast reliable file service is one of the most important elements of any production computing environment. Dedicated FS file servers have been around for more than a decade. They offer a host of potential advantages over the homebrew approach. Of the current offerings, Network Appliance makes some very good ones. www.netapp.com Chapter 17 -The Network File System

Chapter 17 -The Network File System 6. Automatic Mounting Mounting filesystems one at a time by listing them in /etc/fstab or /etc/vfstab introduces a number of problems in large networks. Automounters are very important for large networks of machines. Sun has produced automount and there is another package called amd that is open source and very good. The next two sections of the text cover these programs. Chapter 17 -The Network File System

Chapter 17 -The Network File System 9. Recommended Reading Callaghan, Brent. NFS Illustrated. Addison-Wesley, 1999. Pendy, Jan-Simon, and Nick Williams. “AMD: The 4.4BSD Automounter Reference Manual.” 4.4 BSD System Manager’s Manual, Usenix and O’Rielly. 1994. Stern, Hal. Manageing NFS and NIS. Sebastopol: O’Rielly & Associates, 1992. Chapter 17 -The Network File System

Chapter 17 -The Network File System 9. Recommended Reading Table 17.13 pg 512 Chapter 17 -The Network File System

Chapter 17 -The Network File System