Kerberized NFSv3 incorrect behavior

[George Mamalakis]

Dear all,

I sent this same email to freebsd-stable list as well, but I maybe had 
to sent it to -CURRENT since NFSv4 under fbsd is still experimental, and 
hence under development (and thus nvsv3-gssapi as well -I assumed-). If 
my assumption is wrong, please excuse me and discard this email.

I am running FBSD8-STABLE on an nfsv3 server and an nfsv3 client. My 
configuration is based on 
http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup. My 
goal is to share filesystems securely with gssapi support. 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:

/etc/rc.conf:

rpcbind_enable="YES"
mountd_flags="-e"
nfs_server_enable="YES"
nfs_client_enable="YES"
gssd_enable="YES"

and the kernel is compiled with:

options KGSSAPI
device crypto

my /etc/exports contains:

/exports    -alldirs -sec=krb5

nfs client:

/etc/rc.conf:

rpcbind_enable="YES"
nfs_client_enable="YES"
gssd_enable="YES"


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

[realms]
EXAMPLE.COM = {
kdc = kdc.example.com
admin_server = kdc.example.com
kpasswd_server = kdc.example.com
}

[domain_realm]
kdc.example.com    = EXAMPLE.COM
.kdc.example.com   = EXAMPLE.COM
.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 server.example.com:/exports /mnt
# mount
/dev/da0s1a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
server.example.com:/exports 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 
/mnt/mamalos/myfilethatshouldnotbe

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 obtained 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 (or if the 
ticket has expired), they will still have all permissions as when they 
obtained their ticket.

Thank you all in advance,

looking forward to an answer,

kind regards,

mamalos

-- 
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