Kerberized NFSv3 incorrect behavior

George Mamalakis mamalos at
Fri Feb 5 09:41:00 UTC 2010

Dear all,

I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My 
configuration is based on My 
goal is to share filesystems securely through kerberos authentication. 
Everything works fine, until I try to kdestroy my tickets or kinit to 
some other user, where the system insists to think that I am the user 
that initially obtained their ticket. To be more extensive, my story is 
as follows:

nfs server:



and the kernel is compiled with:

options KGSSAPI
device crypto

my /etc/exports contains:

/exports    -alldirs -sec=krb5

nfs client:



on both client and server the /etc/krb5.conf contains:
default_realm = EXAMPLE.COM

kdc =
admin_server =
kpasswd_server =

[domain_realm]    = EXAMPLE.COM   = EXAMPLE.COM                    = EXAMPLE.COM                     = EXAMPLE.COM

and both client and server have the correct entries about each other 
(and themselves) in their /etc/hosts, so heimdal works just fine.

Both client and server have their respective keytabs stored in 
/etc/krb5.keytab, and I use two users in my example (that both exist in 
both systems with the same uid,gid): mamalos and testakis.

So, when I mount the exported filesystem on the client giving:

# mount -o nvfsv3,sec=krb5 /mnt
# mount
/dev/da0s1a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel) on /mnt (nfs)

and try to access the share:
# ls /mnt
ls: mnt: Permission denied

I get the error I am expecting, since root does not have any kerberos 
tickets assigned, yet. Let's see what happens when I kinit as mamalos:
# klist
Credentials cache: FILE:/tmp/krb5cc_0
         Principal: mamalos at EXAMPLE.COM

   Issued           Expires          Principal
Feb  5 11:20:49  Feb  5 21:20:47  krbtgt/EXAPMLE.COM at EXAMPLE.COM
# ls -la /mnt/
total 8
drwxr-xr-x   4 root      wheel  - 512  4  Feb 19:03 ./
drwxr-xr-x  21 root      wheel  - 512  3 Feb 11:27 ../
drwx------   2 mamalos   wheel  - 512  5 Feb 11:11 mamalos/
drwx------   2 testakis  wheel  - 512  4 Feb 19:06 testakis/
# touch /mnt/mamalos/myfile
# ls -la /mnt/mamalos/myfile
rw-r--r--  1 mamalos  wheel  - 0  5 Feb 11:22 /mnt/mamalos/myfile

Which is the exact behavior that is expected. Now when I kdestroy:
# kdestroy
# klist
klist: No ticket file: /tmp/krb5cc_0
# touch /mnt/mamalos/myfilethatshouldnotbe
# ls -la /mnt/mamalos/myfilethatshouldnotbe
-rw-r--r--  1 mamalos  wheel  - 0  5 Feb 11:24 

And I can do everything in that share as if I were still mamalos, even 
though I kdestroyed my kerberos ticket. The same thing will happen even 
if I kinit to testakis after that. klist shows testakis' ticket this 
time, but I am not allowed to access (rwx) tetakis' files/folders, and I 
still have full control over mamalos' files and folders.

In order to be able to do something as testakis, I have to unmount the 
share and remount it while having testakis' ticket (or having no ticket 
at all, and giving kinit testakis after mounting the share).

I am not an NFS expert, but I suppose that this behavior is not the one 
to be expected, except if I am missing some fundamental information 
about kerberized NFS that explains it. Even so, it would be quite unwise 
to behave so, since even if the users kdestroys their tickets, they have 
still all permissions as when they obtained their ticket.

Thank you all in advance,

looking forward to an answer,

kind regards,


George Mamalakis

IT Officer
Electrical and Computer Engineer (Aristotle Un. of Thessaloniki),
MSc (Imperial College of London)

Department of Electrical and Computer Engineering
Faculty of Engineering
Aristotle University of Thessaloniki

phone number : +30 (2310) 994379

More information about the freebsd-stable mailing list