The Network File System

1. The Network File System Chapter 17

2. 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

3. 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

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

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

28. 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

29. 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

30. 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

31. 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

32. 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

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

34. Chapter 17 -The Network File System