Possible bug in NFSv4 with krb5p security?

Benjamin Kaduk kaduk at MIT.EDU
Fri Feb 15 17:42:36 UTC 2013

On Sat, 16 Feb 2013, Elias Mårtenson wrote:

> Thank you. I did exactly that and I found out some more.
> The problem occurss in file gss.c, in the
> function gssd_pname_to_uid_1_svc(). This function is responsible for taking
> a principal and returning the Unix user ID that this principal corresponds
> to. I did confirm that this function is called with elias at REALM, which is
> the correct principal. It then calls the libgssapi function
> gss_pname_to_uid() which does the actual lookup.
> The problem is that after the lookup (which succeeds by the way), it
> returns user ID 0 (i.e. root, what!?). Of course, this uid later gets
> mapped to nobody, resulting in the behaviour that I see.
> I tried to add more debugging information in libgssapi.so.10, but if I just
> try to add some printf() statements, the entire thing hangs. I'm not sure
> how to proceed from there.
> Oh, and the libgssapi function gss_pname_to_uid() actually delegates the
> actual lookup to a function that depends on what security mechanism is in
> place. My printf()'s (that caused the hang) attempted to print what
> mechanism was actually used.

Unless things are very messed up, it should be using the krb5 mechanism, 
which I believe will boil down to krb5_aname_to_localname, per 
heimdal/lib/gssapi/krb5/pname_to_uid.c.  I'm not sure how this would end 
up with success but uid 0, though.
Do you have the default realm set in krb5.conf?  Having it set to a 
different value than the realm of elias at REALM could result in strange 

> And yet one more thing: Heimdal ships with its own version of libgssapi. I
> can link gssd to it, but it won't run properly (it hangs pretty early).

I have forgotten: you are using Heimdal from ports, not from the base 
system?  I remember it being easy to get into subtly-broken configurations 
when both a ports and a base version are present.

-Ben Kaduk

More information about the freebsd-current mailing list