Articles such as this one seem to point out that Kerberizing NFS(v4) mounts not only prevents machines without a Kerberos service ticket from mounting the shared directory but also uses the user's Kerberos ticket to authorize user actions on the shared files.

I quote the relevant part:

Before NFSv4, security on NFS was pretty much non-existant. You could prevent unauthorized machines from connecting to NFS exports, but had to rely on user ID mappings being the same between systems to use the server's permissions to adequately protect files. Using Kerberos in this manner makes NFS much more secure than it used to be.

What I'm having trouble understanding is the following scenario, which seems to contradict this statement:

# mount /share #succeeds because I have a service ticket in my keytab
$ klist
klist: No credentials cache found (ticket cache FILE:....)
$ ls /share
ls: cannot access /share: Permission Denied
$ kinit
Password for joe@MYREALM:
$ ls /share
contents of share

So far so good, but when I do this:

$ kdestroy
$ ls /share
contents of share

What's happening here? I was able to access the NFS mountpoint even though I had no Kerberos credentials. Is this behavior expected or is my mount misconfigured?


  1. Running MIT Kerberos V on Debian Wheezy 7.0
  2. My mount options:

    $ grep nfs4 /etc/fstab
    server.myrealm:/nfs_export /share nfs4 sec=krb5,user 0 0
  3. My /etc/exports on the server:

    /nfs_export *(rw,sync,no_subtree_check,sec=krb5)

The nfs(5) page says that the GSS API supports two additional flavors of Kerberos security: krb5i to check data integrity and detect any tampering and krb5p to further ensure that all RPC calls are encrypted for security. I don't think enabling either of these will solve my problem.


As per dawud's suggestion I tried both krb5i and krb5p and the behavior persists.

My problem, again, is how to make sure the /share is inaccessible to anyone who currently holds no Kerberos ticket? Furthermore, can I use the user's Kerberos ticket for authorization purposes (i.e., control who can access what) as the article I referenced seems to imply?

  • I don't think enabling either of these will solve my problem. Checking wouldn't hurt, if only to rule that out.
    – dawud
    Commented Jul 12, 2014 at 22:11

1 Answer 1


The behavior you are seeing is a result of the way the Linux client deals with credentials. Once it finds a working credential, it caches it in memory. Even after you kdestroy, your (still valid) credentials are cached by the client.

Quoting from http://www.citi.umich.edu/projects/nfsv4/linux/faq/

The kernel code caches the gssapi context that was negotiated using the Kerberos credentials. Destroying the credentials does not destroy the context in the kernel. We plan to change this behavior when moving to use the new key ring kernel support to store credentials and contexts.

Unfortunately, the client still doesn't use the key ring support.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .