- Challenges of File Sharing
- Different Protocols for Different Clients
- Planning File Services
- Using Apple Filing Protocol
- Configuring Apple File Service
- Monitoring AFP Activity
- Using Windows File Service
- Configuring Windows File Service
- Configuring Access and Starting Windows File Services
- Using NFS Share Point Access
- Configuring NFS
- Using FTP File Service
- Configuring FTP Service
- Network-Mounted Share Points
- Preparing for a Network Home Folder
- Configuring Network Mounts
- Controlling Access to Shared Folders
- Troubleshooting File Services
- What Youve Learned
- References
- Chapter Review
This chapter is from the book
This chapter is from the book
This chapter is from the book
Using NFS Share Point Access
Network File System (NFS) is one of the oldest shared file systems. Because of its deep roots among UNIX platforms, it is still used in a number of situations today. It is considerably different from either the AFP or SMB service. The most outstanding difference is that NFS does not support user logins. When you try to connect to Windows or Apple services without a valid Kerberos ticket, the first thing you do is identify yourself with a user name and password. In the absence of a Kerberos ticket, NFS does not give access to users; it gives access to computers. More accurately, it gives access to particular IP addresses. If your computer has one of these IP addresses, the NFS service lets you connect. Without a Kerberos ticket, it won’t prompt you for a user name or password.
Starting with Mac OS X Server v10.3, NFS file and file-range locks (standard POSIX advisory locks) are enabled by default. This means that two users can safely edit the same file concurrently, as long as they are not editing the same section of the file. If two users attempt to modify the same section of a file, one is locked out in read-only mode until the other is done saving changes.
Mac OS X Server v10.5 and v10.6 use NFSv4, which adds the ability to use Kerberos v5 for identification and authentication for NFS.
NFS Trusts the Client for User Authentication
If NFS doesn’t prompt you for a user name and password, how can it deal with permissions? If you sit down at a client computer and start using an NFS volume, how does it know if you’re a member of the group that has access? Who does it assign as the owner of a file you create?
The server simply believes what the client tells it, based upon the user ID provided by the client. The client tells the server that user Jim is creating a folder or deleting a file, and the server believes it. If Jim has access to that file or folder, the operation is allowed. In Mac OS X, the user that the client reports to the server is normally the user who logged in at the login window. Two issues arise with this method of user identification:
- User mismatch: Maybe the user really is Jim, and your client is correctly reporting his identity to the server. What if the server doesn’t know who Jim is? Or what if there are different Jims—one on the server and one on the client? Remember that each Mac OS X client has a list of users (configured in Accounts preferences), and Mac OS X Server has its own list of users (configured in Workgroup Manager). The two lists may not have any common users, or they may have users who appear to be the same but only coincidentally have the same information. NFS can’t keep this straight on its own.
- Identity theft: Imagine you are a standard user on the server, but you are the administrator of your own MacBook running Mac OS X. Because you control that MacBook, you can create any user you want locally and thus pretend to be anyone you want to be. You can now see why NFS is a security concern.
NFS Options to Increase Security
One response to the problem of identity theft is to map NFS users. Rather than accept what the client reports, the server can simply pretend that the user is “nobody,” and hence the user gets the permissions that are assigned to everyone. You’ll almost certainly want to select this mapping for the root user—the all-powerful superuser who can delete any item on a volume. It is just as easy to steal the root user’s identity as it is any other user’s. Beyond this, you can map all users to nobody and just ignore altogether what the client is reporting for a user. Checking both these options is similar to giving guest access under AFP.
The Minimum Security pop-up menu offers a number of options to increase the level of security for sharing files over NFS:
- Standard—Use only IP address to grant access to the NFS service
- Any—Accept any method of authentication
- Kerberos v5—Accept only Kerberos authentication
- Kerberos v5 with data integrity—In addition to accepting only Kerberos authentication, checksum the data transfer
- Kerberos v5 with data integrity and privacy—In addition to accepting only Kerberos authentication, checksum and encrypt the data transfer
If you need to provide NFS services only to computers with Mac OS X v10.5 or Mac OS X v10.6, it is recommended that you choose an option that includes Kerberos for the Minimum Security setting for NFS service.