Possible bug in NFSv4 with krb5p security?
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.
More information about the freebsd-current