286 NFS • Example #1: NFS is stateless, but many programs designed for Unix systems require record locking in order to guarantee database consistency. NFS Hack Solution #1: Sun invented a network lock protocol and a lock daemon, lockd. This network locking system has all of the state and associated problems with state that NFS was designed to avoid. Why the hack doesn’t work: Locks can be lost if the server crashes. As a result, an elaborate restart procedure after the crash is necessary to recover state. Of course, the original reason for making NFS stateless in the first place was to avoid the need for such restart procedures. Instead of hiding this complexity in the lockd program, where it is rarely tested and can only benefit locks, it could have been put into the main protocol, thoroughly debugged, and made available to all programs. • Example #2: NFS is based on UDP if a client request isn’t answered, the client resends the request until it gets an answer. If the server is doing something time-consuming for one client, all of the other clients who want file service will continue to hammer away at the server with duplicate and triplicate NFS requests, rather than patiently putting them into a queue and waiting for the reply. NFS Hack Solution #2: When the NFS client doesn’t get a response from the server, it backs off and pauses for a few milliseconds before it asks a second time. If it doesn't get a second answer, it backs off for twice as long. Then four times as long, and so on. Why the hack doesn’t work: The problem is that this strategy has to be tuned for each individual NFS server, each network. More often than not, tuning isn’t done. Delays accumulate. Performance lags, then drags. Eventually, the sysadmin complains and the com- pany buys a faster LAN or leased line or network concentrator, thinking that throwing money at the problem will make it go away. • Example #3: If you delete a file in Unix that is still open, the file’s name is removed from its directory, but the disk blocks associated with the file are not deleted until the file is closed. This gross hack allows programs to create temporary files that can’t be accessed by other programs. (This is the second way that Unix uses to create temporary files the other technique is to use the mktmp() function and create a temporary file in the /tmp directory that has the process ID in the filename. Deciding which method is the grosser of the two

No File Security 287 is an exercise left to the reader.) But this hack doesn’t work over NFS. The stateless protocol doesn't know that the file is “opened” — as soon as the file is deleted, it's gone. NFS Hack Solution #3: When an NFS client deletes a file that is open, it really renames the file with a crazy name like “.nfs0003234320” which, because it begins with a leading period, does not appear in normal file listings. When the file is closed on the client, the client sends through the Delete-File command to delete the NFS dot-file. Why the hack doesn’t work: If the client crashes, the dot-file never gets deleted. As a result, NFS servers have to run nightly “clean-up” shell scripts that search for all of the files with names like “.nfs0003234320” that are more than a few days old and automatically delete them. This is why most Unix systems suddenly freeze up at 2:00 a.m. each morning—they’re spinning their disks running find. And you better not go on vacation with the mail(1) program still running if you want your mail file to be around when you return. (No kidding!) So even though NFS builds its reputation on being a “stateless” file system, it’s all a big lie. The server is filled with state—a whole disk worth. Every single process on the client has state. It’s only the NFS protocol that is stateless. And every single gross hack that’s become part of the NFS “stan- dard” is an attempt to cover up that lie, gloss it over, and try to make it seem that it isn’t so bad. No File Security Putting your computer on the network means potentially giving every pim- ply faced ten-year-old computer cracker in the world the ability to read your love letters, insert spurious commas into your source code, or even forge a letter of resignation from you to put in your boss’s mailbox. You better be sure that your network file system has some built-in security to prevent these sorts of attacks. Unfortunately, NFS wasn’t designed for security. Fact is, the protocol doesn’t have any. If you give an NFS file server a valid handle for a file, the server lets you play with it to your heart’s content. Go ahead, scribble away: the server doesn’t even have the ability to log the network address of the workstation that does the damage.