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?
- Running MIT Kerberos V on Debian Wheezy 7.0
My mount options:
$ grep nfs4 /etc/fstab server.myrealm:/nfs_export /share nfs4 sec=krb5,user 0 0
/etc/exportson the server:
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
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?