NFS client: RPCSEC_GSS w/ Kerberos over TCP

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/

Yes.

Might be worth either reporting to redhat or retesting with the most recent upstream kernel.

Right, we'd have to look closer to be sure. Might be worth grepping the freebsd code for returns of GSS_S_DEFECTIVE_TOKEN and seeing if that helps pin down what its complaint is.

--b.