From owner-freebsd-current@FreeBSD.ORG Fri Feb 15 17:42:36 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 A74CD89B for ; Fri, 15 Feb 2013 17:42:36 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4FB28AB5 for ; Fri, 15 Feb 2013 17:42:35 +0000 (UTC) X-AuditID: 1209190e-b7f266d0000008cb-cf-511e7385ff11 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 9E.B8.02251.5837E115; Fri, 15 Feb 2013 12:42:29 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r1FHgTDF026303; Fri, 15 Feb 2013 12:42:29 -0500 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1FHgQqo010738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 12:42:28 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r1FHgQZZ019574; Fri, 15 Feb 2013 12:42:26 -0500 (EST) Date: Fri, 15 Feb 2013 12:42:26 -0500 (EST) From: Benjamin Kaduk To: =?ISO-8859-15?Q?Elias_M=E5rtenson?= Subject: Re: Possible bug in NFSv4 with krb5p security? In-Reply-To: Message-ID: References: <336731055.3000548.1360798935813.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1646422927-1360950146=:9389" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0W0tlgs0uDlJ3mLOmw9MFk8mcls8 XHaNyYHZY8an+SweO2fdZff4vXkvUwBzFJdNSmpOZllqkb5dAlfG1c4/bAX9QhVTbsU0MN7l 62Lk5JAQMJHYM/cHE4QtJnHh3nq2LkYuDiGBfYwSn99vY4FwNjJKLHn6lBXCOcQkseDYXiin gVFi/bUXLCD9LALaErvubQCz2QRUJGa+2cgGYosIWEvs+rYZyObgYBZwkdi8sBIkLCxgLvHz 5nFGEJtTIFBi8tOVYGfwCjhIbHl3mR1i/k1Gic4ZEAlRAR2J1funsEAUCUqcnPkEzGYWCJA4 9Hs68wRGwVlIUrOQpGaBrbaRmHCvEiKsLXH/ZhvbAkaWVYyyKblVurmJmTnFqcm6xcmJeXmp RbrGermZJXqpKaWbGEGhzinJt4Px60GlQ4wCHIxKPLwCErKBQqyJZcWVuYcYJTmYlER5HxTK BQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4ZW7BVTOm5JYWZValA+TkuZgURLnvZJy019IID2x JDU7NbUgtQgmK8PBoSTBu6IIaKhgUWp6akVaZk4JQpqJgxNkOA/QcE+QGt7igsTc4sx0iPwp RkUpcYhmAZBERmkeXC8sFb1iFAd6RZh3FUgVDzCNwXW/AhrMBDT4zjuQq4tLEhFSUg2MzkxT 2pn43JjnHPfdtfljUaWdaLLcEUareXuW3bv2Ys89v9nHL+Q4vfT5m7vA+Zfj1GOcnIc3ZvAy epRKHFESLbNLkxIoUrBV53vNKpny9LRUweWwp8/Mut7/sRO/9+Shf7uctVHFzAfnZzF/rBNc mRGzaM/1/yalMVr8gvsj8loZZhVPqXdUYinOSDTUYi4qTgQASIuQRiADAAA= Cc: Rick Macklem , freebsd-current@freebsd.org 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: Fri, 15 Feb 2013 17:42:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1646422927-1360950146=:9389 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE 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 taki= ng > a principal and returning the Unix user ID that this principal correspond= s > 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 ju= st > 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,=20 which I believe will boil down to krb5_aname_to_localname, per=20 heimdal/lib/gssapi/krb5/pname_to_uid.c. I'm not sure how this would end=20 up with success but uid 0, though. Do you have the default realm set in krb5.conf? Having it set to a=20 different value than the realm of elias@REALM could result in strange=20 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=20 system? I remember it being easy to get into subtly-broken configurations= =20 when both a ports and a base version are present. -Ben Kaduk ---559023410-1646422927-1360950146=:9389--