Re: Possible bug in NFSv4 with krb5p security?

On 14 February 2013 07:42, Rick Macklem <rmacklem@uoguelph.ca> wrote:

Elias Martenson wrote:> Secondly, what if the issue is gssd not correctly
> mapping the
> > principals to
> > Unix usernames? How can I determine if this is the case. There seems
> > to be
> > no logging options for gssd (-d does absolutely nothing other than
> > prevent
> > the process from detaching. It still doesn't log anything).
> >
> Yep. I added a few cases that output debugging, but they're all on the
> client side. (I wasn't the original author of this gssd.)
>
> You could easily add some. It's the function with pname_to_uid in it
> that does the translation. It basically does a gss_pname_to_uid()
> followed by a getpwuid() to do the translation from principal name
> to uid + gid list. If this fails, then it maps uid == 65534, which
> is usually "nobody". (Why does the code has 65534 hardwired in it?
> I have no idea.;-)
>
> Just add fprintf()s and run it with "-d" to see what it is doing.
>
> If the initiator principal is "nfs/client-host.domain" it will get
> mapped to "nobody" as above.

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@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.

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).

Does anyone have any idea what might be going on here?

Regards,
Elias
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"