NetBSD Problem Report #19206

Received: (qmail 29586 invoked by uid 605); 29 Nov 2002 21:27:10 -0000
Message-Id: <>
Date: Fri, 29 Nov 2002 16:27:08 -0500 (EST)
Subject: GSSAPI using daemons fail when root has a krb5 CC
X-Send-Pr-Version: 3.95

>Number:         19206
>Category:       lib
>Synopsis:       GSSAPI using daemons fail when root has a krb5 CC
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 29 21:28:00 +0000 2002
>Last-Modified:  Thu Dec 12 22:30:05 +0000 2002
>Originator:     Roland Dowdeswell
>Release:        NetBSD 1.6_BETA1
	The Fall of Imrryr
System: NetBSD 1.6_BETA1 NetBSD 1.6_BETA1 (ARIOCH) #0: Fri Jun 28 12:36:20 EDT 2002 alpha
Architecture: alpha
Machine: alpha
     $Heimdal: acquire_cred.c,v 1.10 2002/08/20 12:02:45 nectar Exp $
     $NetBSD: acquire_cred.c,v 1.9 2002/11/28 11:21:16 elric Exp $
	If you are using GSSAPI to negotiate, e.g. IPsec, the
	negotiations will begin to fail if root logs in and runs
	kinit(1).  This, I think, is counter-intuitive behaviour.
	(Of course, since I am running NFS over IPsec, the first
	symptom that I saw was NFS hanging, but...)
	Use GSSAPI w/ racoon or imapd and note that if root performs
	a kinit(1) with the CC in the default location then these
	services begin to fail, claiming that they can't find the
	right principal.
	I think that the right fix is for the GSSAPI code to if it
	is looking for a specific principal to continue to search
	beyond the credentials cache if the cache contains the
	wrong principal.  This is a quick patch which I haven't
	tested but include as a suggestion of how to fix it for
	comment.  If this is generally considered a good start,
	then I shall fix it up, test it and check it in.  Most
	notably, I have not yet paid attention to cleanup and
	memory allocation issues.
Index: acquire_cred.c
RCS file: /cvsroot/basesrc/crypto/dist/heimdal/lib/gssapi/acquire_cred.c,v
retrieving revision 1.9
diff -u -r1.9 acquire_cred.c
--- acquire_cred.c	2002/11/28 11:21:16	1.9
+++ acquire_cred.c	2002/11/29 21:25:24
@@ -96,8 +96,13 @@
     } else if (handle->principal != NULL &&
 	krb5_principal_compare(gssapi_krb5_context, handle->principal,
 	def_princ) == FALSE) {
-	goto end;
+	/*
+	 * this is the wrong principal, but that doesn't mean that the
+	 * keytab does not contain the correct principal.  Clean up
+	 * the principal and fall through.
+	 */
+	krb5_free_principal(gssapi_krb5_context, def_princ);
+	def_princ = NULL;             
     if (def_princ == NULL) {
 	/* We have no existing credentials cache,

From: Roland Dowdeswell <>
Subject: Re: lib/19206: GSSAPI using daemons fail when root has a krb5 CC 
Date: Thu, 12 Dec 2002 17:29:24 -0500

 Upon further examination, this does not affect all daemons that
 use GSSAPI but those that try to acquire both acceptor and initiator
 credentials.  This is the case for racoon(8), but not imapd as I
 claimed in the PR.  The problem is when the initiator credentials
 are acquired.  I still think that a solution similar to the proposed
 solution should be used, but it will take a little more thought to
 verify that it is the correct thing to do.

     Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.