NFS Mount Example

This section follows an NFS mount request from start to finish using AUTH_KERB. Because mount requests are executed as root, the user's identity is root.c.

Client c makes a MOUNTPROC_MOUNT request to the server s to obtain the file handle for the directory to be mounted. The client mount program makes an NFS mount system call, handing the client kernel the file handle, mount flavor, time synchronization address, and the server's well-known name, nfs.s. Next the client kernel contacts the server at the time synchronization host to obtain the client-server time bias.

The client kernel makes the following RPC calls.

1. KSETKCRED to the local kerbd to obtain the ticket and session key,

2. NFSPROC_GETATTR to the server's NFS service, using the full name credential and verifier. The server receives the calls and makes the KGETKCRED call to its local kerbd to check the client's ticket.

The server's kerbd and the Kerberos library decrypt the ticket and return, among other data, the principal name and DES session key. The server checks that the ticket is still valid, uses the session key to decrypt the DES-encrypted portions of the credential and verifier, and checks that the verifier is valid.

The possible Kerberos authentication errors returned at this time are:

• AUTH_BADCRED is returned if the verifier is invalid because the decrypted win in the credential and win +1 in the verifier do not match, or the timestamp is not within the window range.

• AUTH_REJECTEDCRED is returned if a replay is detected.

• AUTH_BADVERF is returned if the verifier is garbled.

If no errors are received, the server caches the client's identity and allocates a nickname, which is a small integer, to be returned in the NFS reply. The server then checks if the client is in the same realm as the server. If so, the server calls KGETUCRED to its local kerbd to translate the principal's primary name into UNIX credentials. If the previous name is not translatable, the user is marked anonymous. The server checks these credentials against the file system's export information. Consider these three cases:

1. If the KGETUCRED call fails and anonymous requests are allowed, the UNIX credentials of the anonymous user are assigned.

2. If the KGETUCRED call fails and anonymous requests are not allowed, the NFS call fails with the AUTH_TOOWEAK.

3. If the KGETUCRED call succeeds, the credentials are assigned, and normal protection checking follows, including checking for root permission.

Next, the server sends an NFS reply, including the nickname and server's verifier. The client receives the reply, decrypts and validates the verifier, and stores the nickname for future calls. The client makes a second NFS call to the server, and the calls to the server described previously are repeated. The client kernel makes an NFSPROC_STATVFS call to the server's NFS service, using the nickname credential and verifier described previously. The server receives the call and validates the nickname. If it is out of range, the error AUTH_BADCRED is returned. The server uses the session key just obtained to decrypt the DES-encrypted portions of the verifier and validates the verifier.

The possible Kerberos authentication errors returned at this time are:

• AUTH_REJECTEDVERF, which is returned if the timestamp is invalid, a replay is detected, or if the timestamp is not within the window range

• AUTH_TIMEEXPIRE, which is returned if the service ticket is expired

If no errors are received, the server uses the nickname to retrieve the caller's UNIX credentials. Then it checks these credentials against the file system's export information, and sends an NFS reply that includes the nickname and the server's verifier. The client receives the reply, decrypts and validates the verifier, and stores the nickname for future calls. Last, the client's NFS mount system call returns, and the request is finished.