NFS client: RPCSEC_GSS w/ Kerberos over TCP

["Attila Bogár" <attila.bogar@linguamatics.com>]

Hi,

I'm new on this list, this is my first post.

I can see some interoperability problems between FreeBSD 8 and 9 stable 
NFS servers and some Linux NFS clients when using Kerberized NFS.

I noticed that around nfs-utils 1.2.3 something must have changed on the 
Linux side or the Linux became more agile to trigger a bug with the FreeBSD.

Maybe these issues have been reported or fixed, but on a current RHEL 
6.3 and Ubuntu 12.04 LTS they still do exist.

When the Linux clients mount a FreeBSD NFS share (v3 or v4) sec=krb5*, 
they sometimes get an access denied.
If they are able to mount anyway, then subsequent NFS I/O errors continue.

So far:
http://lists.freebsd.org/pipermail/freebsd-fs/2012-August/015047.html
http://lists.freebsd.org/pipermail/freebsd-fs/2012-September/015050.html

I have some questions.  As this is an interop problem, I'd like to 
clarify a few things.

This what I see on the wireshark trace during an NFSv4 mount -o 
proto=tcp,sec=krb5:
The client is EL6 with a patched nfs-utils package as per: 
https://bugzilla.redhat.com/show_bug.cgi?id=802469 and gssd started with 
-l (legacy) option

TCP0: -> Linux NFS AUTH_NULL
TCP0: <- FreeBSD responds

TCP1: -> Linux sends RPCSEC_GSS_INIT
TCP1: <- FreeBSD responds by establishing GSS Context (it's a 16 byte token)

TCP1: -> Linux sends RPCSEC_GSS_DESTROY using the received 16 byte token
TCP0: -> Linux sends NFS:PUTROOTFS|GETATTR using the same 16 byte received gss context token


Re-using the gss context on the other tcp connection and immediately 
destroying it looks like a bug in the Linux NFS layer?

Another worry I see, is that the RPCSEC_GSS_DESTROY when validated on 
the FreeBSD side gss_verify_mic returns maj_stat = GSS_S_DEFECTIVE_TOKEN 
- which is quite strange (this still can be a FreeBSD bug).

Kind regards,
   Attila

-- 
Attila Bogár
Systems Administrator
Linguamatics - Cambridge, UK
http://www.linguamatics.com/