Need hints debugging KGSSAPI

[Rick Macklem]

Attila wrote:
> Hi,
> 
> I'd like to spend some time finding out myself what's wrong with the
> kerberized nfs server on the FreeBSD 9-STABLE.
> 
> I thought the solution is to simply force DES+RFC1964 GSSAPI, but
> unfortunately it's not that simple.
> I built a patched nfs-utils package by merging the patch referenced
> from
> https://bugzilla.redhat.com/show_bug.cgi?id=802469 - with the legacy
> option did not resolve the problem.
> 
> I have some wireshark traces which show that one EL6 box get 3 times
> auth_denied however the other succeeds for the 3rd time. I can
> reproduce this.
> 
> My kernel is a GENERIC + some option as per Rick's page:
> options KGSSAPI
> device crypto
> device cryptodev
> 
> I know, that all interesting NFS/GSSAPI job is done within kernel
> space.
> 
Not exactly. All the KGSSAPI does is package up the arguments for the
GSS api call and then do an upcall to the userland gssd. The userland
gssd does the GSS api call against the Kerberos libraries it has been
linked to and then passes the results of that call back down into the
kernel. So, once you get past the RPCSEC_GSS stuff and down to the
actual GSS API call, it is the userland Kerberos libraries that do the
interesting stuff. (There are a few tricks, like a "hidden effective uid
argument" for init_sec_context(), but mostly the KGSSAPI/gssd just passes
arguments between the kernel call and the userland Kerberos library.)

> I suppose it's not possible to unload the KGSSAPI module:
> http://svnweb.freebsd.org/base/head/sys/kgssapi/gss_impl.c?view=markup&pathrev=224084
> 
> What's the best way to debug the kernel other than inserting debug
> messages into the source tree+recompiling+rebooting?
> 
I'm an old fashioned printf() guy, so that's what I do. If it appears that
it is the upcall to the userland gssd that generates a failed reply, then
the problem is most likely the userland Kerberos libraries. (I'd probably
cram a pile of printf()s in the rpcsec_gss and kgssapi sources, especially
at the kgssapi upcalls to the userland gssd, to try and figure out where
the "authentication failure" is occurring.)

I've already emailed this person w.r.t. making sure he isn't seeing the
"non-atomic export update" problem. Since mountd deletes all exports and
then re-adds them non-atomically, the security flavours allowed will be
messed up whenever mountd gets a HUP signal. (This happens automagically
whenever a "mount" of a file system happens on the NFS server, since
"mount" sends "mountd" a HUP signal.)

If it is the userland Kerberos libraries, I'd try installing a vanilla
up to date Heimdal distro (it usually installs easily in somewhere like
/usr/heimdal) and then I'd rebuild gssd.c linked to those libraries and
see if I could get that to work. Long ago, to get kerberized NFS to work
on OpenBSD, I'd statically link the gssd I had for it (very different than
the FreeBSD gssd) to freshly built Heimdal libraries.

rick

> What debugger do you recommend?
> Is there an up-to-date tutorial on FreeBSD kernel debugging?
> 
> Any constructive comments appreciated.
> 
> Thanks,
> Attila
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"