From owner-freebsd-current@FreeBSD.ORG Sat Feb 16 00:57:37 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 473F8508 for ; Sat, 16 Feb 2013 00:57:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 01140129 for ; Sat, 16 Feb 2013 00:57:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEABfZHlGDaFvO/2dsb2JhbABEDoY7uUqBE3OCHwEBBSMEUhsYAgINBQISAlkGiCWrIpIsgSONVDQHEgYGgg+BEwOIZo1CkFWCSF2BVDU X-IronPort-AV: E=Sophos;i="4.84,676,1355115600"; d="scan'208";a="14360145" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 15 Feb 2013 19:57:08 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CB20FB3F45; Fri, 15 Feb 2013 19:57:08 -0500 (EST) Date: Fri, 15 Feb 2013 19:57:08 -0500 (EST) From: Rick Macklem To: Benjamin Kaduk Message-ID: <738556090.3072349.1360976228786.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: Possible bug in NFSv4 with krb5p security? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org, =?utf-8?Q?Elias_M=C3=A5rtenson?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 00:57:37 -0000 Benjamin Kaduk wrote: > On Sat, 16 Feb 2013, Elias M=C3=A5rtenson wrote: >=20 > > > > 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. >=20 > 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@REALM could result in strange > behavior. >=20 > > 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). >=20 > 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. >=20 > -Ben Kaduk Well, here's the aname_to_localname function sources. After this, it just calls getpwnam_r() to get the password database entry for the name. I've put "***" in front of what I suspect is causing your problem. I have no idea when there is a name_string.len =3D=3D 2 with "root" as the second string. Maybe Benjamin knows? krb5_error_code KRB5_LIB_FUNCTION krb5_aname_to_localname (krb5_context context, =09=09=09 krb5_const_principal aname, =09=09=09 size_t lnsize, =09=09=09 char *lname) { krb5_error_code ret; krb5_realm *lrealms, *r; int valid; size_t len; const char *res; ret =3D krb5_get_default_realms (context, &lrealms); if (ret) =09return ret; valid =3D 0; for (r =3D lrealms; *r !=3D NULL; ++r) { =09if (strcmp (*r, aname->realm) =3D=3D 0) { =09 valid =3D 1; =09 break; =09} } krb5_free_host_realm (context, lrealms); if (valid =3D=3D 0) =09return KRB5_NO_LOCALNAME; if (aname->name.name_string.len =3D=3D 1) =09res =3D aname->name.name_string.val[0]; *** else if (aname->name.name_string.len =3D=3D 2 =09 && strcmp (aname->name.name_string.val[1], "root") =3D=3D 0) { =09krb5_principal rootprinc; =09krb5_boolean userok; =09res =3D "root"; =09ret =3D krb5_copy_principal(context, aname, &rootprinc); =09if (ret) =09 return ret; =09 =09userok =3D krb5_kuserok(context, rootprinc, res); =09krb5_free_principal(context, rootprinc); =09if (!userok) =09 return KRB5_NO_LOCALNAME; } else =09return KRB5_NO_LOCALNAME; len =3D strlen (res); if (len >=3D lnsize) =09return ERANGE; strlcpy (lname, res, lnsize); return 0; } I've never seen Kerberos map to "root" like the above would for name.name_string.len =3D=3D 2, but I'm guessing that's how you get uid =3D=3D 0. rick