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 behavior. > 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 KadukReceived on Fri Feb 15 2013 - 16:42:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:34 UTC