From owner-freebsd-current@FreeBSD.ORG Fri Feb 15 17:06:18 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 CB07ACA9 for ; Fri, 15 Feb 2013 17:06:18 +0000 (UTC) (envelope-from lokedhs@gmail.com) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 4633F94B for ; Fri, 15 Feb 2013 17:06:18 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id eb20so3709318lab.17 for ; Fri, 15 Feb 2013 09:06:17 -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=0liCVaFfNDgAAf3vCYj5t5o6VfCMpWxzyRqPhQgjEmI=; b=mXaL2HRVzCzxW3AwvQf+S8kcaVMxAetkV5FxLQxTo5+WKOWQ1JIAHjBgwQzNc6u+Yg b45yRFg/7mvIHuqneibuLMkPHVIuswBsL+/qryWSt3zvk9O5IDzSuG1PU5lu+8XT8z/g yIlgWq6eGfBQwnDvNSkaY8BjAVIUhHVWZAGa/D/1gkHPA8FjuetcGP9BOnyK7tZJu9RT HN5wNY9j5rrLj7YcYDaItrLJWeGYOAGivCKWXDeNbVk3ykneQOULikoybn2zG3LjAZWB X55/6zK/Z1wTWn05BY1MmH900VgRetDlKPEUQH65znmzcxTmTD2eFGt9cXRp9+XWhjiE KJkw== MIME-Version: 1.0 X-Received: by 10.112.39.138 with SMTP id p10mr2405066lbk.31.1360947977114; Fri, 15 Feb 2013 09:06:17 -0800 (PST) Received: by 10.112.41.68 with HTTP; Fri, 15 Feb 2013 09:06:16 -0800 (PST) In-Reply-To: <336731055.3000548.1360798935813.JavaMail.root@erie.cs.uoguelph.ca> References: <336731055.3000548.1360798935813.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 16 Feb 2013 01:06:16 +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 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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:06:18 -0000 On 14 February 2013 07:42, Rick Macklem 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