From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 21:28:29 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06FFB106564A for ; Fri, 21 Sep 2012 21:28:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B086E8FC0C for ; Fri, 21 Sep 2012 21:28:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAB/bXFCDaFvO/2dsb2JhbABFhgu0XoRAgiABAQUjBFIzAgINGQJZBogYpkOSe4EhiXuFFIESA5VkkCKDA4FHNA X-IronPort-AV: E=Sophos;i="4.80,465,1344225600"; d="scan'208";a="182731043" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 21 Sep 2012 17:28:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 071A0B4048; Fri, 21 Sep 2012 17:28:22 -0400 (EDT) Date: Fri, 21 Sep 2012 17:28:22 -0400 (EDT) From: Rick Macklem To: FreeBSD-Current Message-ID: <627814917.1029105.1348262902010.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <505C1A99.4080800@ist.tugraz.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Herbert Poeckl Subject: open-sshd uses non-default Kerberos cred cache breaking Kerberized NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Sep 2012 21:28:29 -0000 Herbert emailed with a problem using the kerberized NFS client in FreeBSD. He has been able to isolate the problem to the fact that the sshd he uses (from open-sshd in ports) uses a non-default tgt credentials cache. The problem is that the gssd sets KRB5CCNAME to /tmp/krb5cc_, where is the effective uid of the process doing the NFS RPC, so that it can do an init_sec_context() GSSAPI call to get the GSSAPI token. This fails if the tgt is in a credentials cache file under a different name. Here's the code snippet from gssd.c: snprintf(ccname, sizeof(ccname), "FILE:/tmp/krb5cc_%d", (int) argp->uid); setenv("KRB5CCNAME", ccname, TRUE); I can't think of any way to fix this, since the gssd runs as effective uid==0 and needs to access the credentials cache for other users. Can anyone conversant with Kerberos suggest a fix? Or does anyone know if there is an easy way to tell open-sshd to use the default credential cache file name? If not, all I can think of is to document this in gssd.8. Thanks in advance for any help with this, rick [Herbert Poeckl wrote in an email to me, copied with his permission] > Hi Rick, > > On 09/20/2012 11:45 PM, Rick Macklem wrote: > >>> Ok, after the mount, if you log in as a non-root user, kinit as > >>> that > >>> user to get a tgt, then try and access the mount point... "what > >>> happens"? > >> > >> And then the request for root@IST.INTRA happens. > >> > > If you can capture packets from the mount until this happens and > > email > > it to me, hopefully I can spot when this happens. For example, try > > something like: > > # tcpdump -s 0 -w file.pcap host srv.ist.intra > > - then in another window > > # mount -t nfs -o nfsv4,gssname=host,sec=krb5 srv.ist.intra:/ > > /mnt > > # > > - then in a window logged into a non-root user that has kinit'd > > % ls /mnt > > - and whatever else it takes to cause it to access root@IST.INTRA, > > which > > shouldn't happen. (It should use the non-root user's principal or > > the > > host/soy.ist.intra@IST.INTRA one.) > > > > My guess is that some recent change has confused it so it tries to > > use a > > credential for uid 0. > > I did some more testing. > > This is what I found out: > > If the environment variable KRB5CCNAME for the user is not set, or is > set to FILE:/tmp/krb5cc_20001 (user with uidnumber 20001) then > everything works as expected! > > If the environment variable is set to something different, which > happens > when the user logs in with SSH, like FILE:/tmp/krb5cc_20001_HNYQhqGftu > then I get the problem as described (request for root@IST.INTRA). > > Herbert