Possible bug in NFSv4 with krb5p security?

[Elias Mårtenson]

On 17 February 2013 22:58, Rick Macklem <rmacklem at uoguelph.ca> wrote:

I think the Makefiles are in the kerberos5 directory.
>
> Since the only function you care about is the one in
> kerberos5/lib/libgssapi_krb5/pname_to_uid.c, I'd
> just put a copy of that file in usr.sbin/gssd and
> modify the Makefile there to compile it and link
> its .o into gssd, avoiding rebuilding any libraries.
>
> I'd put a couple of fprintf(stderr, ...) in it and
> then run "gssd -d" and see what it says.
>
> Just how I'd attack it, rick


Good news! The problem is solved!

You were right, the problem was in pname_to_uid.c. In it, the following
code can be found:

        char lname[MAXLOGNAME + 1], buf[1024];

        /* some code snipped for brevity... */

        getpwnam_r(lname, &pwd, buf, sizeof(buf), &pw);
        if (pw) {
                *uidp = pw->pw_uid;
                return (GSS_S_COMPLETE);
        } else {
                return (GSS_S_FAILURE);
        }

As it turns out, the getpwnam_r() call fails with ERANGE (I had to check
the return value from getpwnam_r() in order to determine this, as pw is set
to NULL both if there was an error or if the user name can't be found).

Now, increasing the size of buf to 1024 solved the problem, and now the
lookup works correctly.

I wrote a small test program that issued the same call to getpwnam_r() and
it worked. Until I su'ed to root, and then it failed.

It seems as though the buffer needs to be bigger if you're root. I have no
idea why, but there you have it. Problem solved.

Should this be fixed in the main codebase?

Oh, and thanks so much to all of you for being patient with me while
solving this. I really appreciate it. Also, I'd like to say that the code
base was quite pleasant to work with. Thanks for that too. :-)

Regards,
Elias