From owner-freebsd-current@FreeBSD.ORG Sat Feb 16 01:31:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76CF315D for ; Sat, 16 Feb 2013 01:31:39 +0000 (UTC) (envelope-from lokedhs@gmail.com) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mx1.freebsd.org (Postfix) with ESMTP id D3D4F1F8 for ; Sat, 16 Feb 2013 01:31:38 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id ge1so3062539lbb.15 for ; Fri, 15 Feb 2013 17:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vOty2iD63fI4WPgxrpeHkqZKX5WTQfxlm95VP9dKj7M=; b=CkoRAlFyollDFNjpgXg/Dk4Jv5pcQXLYujrkapRE8UuQg1kf7VnhWRhBdjSpzDauLy HhH3oseSPNzWi5gX5OWtRJb3FqXBpXf/y+alwfILoqw+qqM6Yt58b3bvay7kJnxkRng8 XkNAoZqO4IJATSlmd1G/w9eBe45WUq4rbVen9OVFwKmlshRp1W3DLvDri6uThqmdzou/ IFAfnxSXv7qKlD2sCkQdSuEbJ932oFS6N2CanUGBXbTBdJAA0Vta1gGrntxZEyDXekfm w+WzA3Pxenruh6xvDkZ8miaRx+Z9UNA3pLcYpsreI2loSvB3MPw3fPzOheXkS+rLeJd1 263w== MIME-Version: 1.0 X-Received: by 10.112.25.8 with SMTP id y8mr2831862lbf.81.1360978292394; Fri, 15 Feb 2013 17:31:32 -0800 (PST) Received: by 10.112.41.68 with HTTP; Fri, 15 Feb 2013 17:31:31 -0800 (PST) Received: by 10.112.41.68 with HTTP; Fri, 15 Feb 2013 17:31:31 -0800 (PST) In-Reply-To: <738556090.3072349.1360976228786.JavaMail.root@erie.cs.uoguelph.ca> References: <738556090.3072349.1360976228786.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 16 Feb 2013 09:31:31 +0800 Message-ID: Subject: Re: Possible bug in NFSv4 with krb5p security? From: =?ISO-8859-1?Q?Elias_M=E5rtenson?= To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org, Benjamin Kaduk 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 01:31:39 -0000 On 16 Feb, 2013 8:57 AM, "Rick Macklem" wrote: > > Benjamin Kaduk wrote: > > On Sat, 16 Feb 2013, Elias M=E5rtenson 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@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@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 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 th= e > second string. Maybe Benjamin knows? > > krb5_error_code KRB5_LIB_FUNCTION > krb5_aname_to_localname (krb5_context context, > krb5_const_principal aname, > size_t lnsize, > 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) > return ret; > > valid =3D 0; > for (r =3D lrealms; *r !=3D NULL; ++r) { > if (strcmp (*r, aname->realm) =3D=3D 0) { > valid =3D 1; > break; > } > } > krb5_free_host_realm (context, lrealms); > if (valid =3D=3D 0) > return KRB5_NO_LOCALNAME; > > if (aname->name.name_string.len =3D=3D 1) > res =3D aname->name.name_string.val[0]; > *** else if (aname->name.name_string.len =3D=3D 2 > && strcmp (aname->name.name_string.val[1], "root") =3D=3D 0)= { > krb5_principal rootprinc; > krb5_boolean userok; > > res =3D "root"; > > ret =3D krb5_copy_principal(context, aname, &rootprinc); > if (ret) > return ret; > > userok =3D krb5_kuserok(context, rootprinc, res); > krb5_free_principal(context, rootprinc); > if (!userok) > return KRB5_NO_LOCALNAME; > > } else > return KRB5_NO_LOCALNAME; > > len =3D strlen (res); > if (len >=3D lnsize) > return 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. Sorry for bad formatting, I'm typing this on my phone. Wouldn't the case you quoted cover the case where you gave a principal name like foo/root which would be mapped to root? I've never seen such principals, but it makes sense based on what I see in the code. Regards, Elias