[krbdev.mit.edu #1199] Local host login results in host ticket that expires in 5 minutes

The RT System itself via RT rt-comment at krbdev.mit.edu
Thu Sep 26 16:49:18 EDT 2002


>From kenh at cmf.nrl.navy.mil  Thu Sep 26 16:49:15 2002
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by krbdev.mit.edu (8.9.3) with ESMTP
	id QAA28215; Thu, 26 Sep 2002 16:49:15 -0400 (EDT)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
	by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA20365
	for <krb5-bugs at mit.edu>; Thu, 26 Sep 2002 16:49:15 -0400 (EDT)
Received: from elvis.cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38])
	by ginger.cmf.nrl.navy.mil (8.12.5/8.12.4) with ESMTP id g8QKnCCj018667
	for <krb5-bugs at mit.edu>; Thu, 26 Sep 2002 16:49:12 -0400 (EDT)
From: Ken Hornstein <kenh at cmf.nrl.navy.mil>
Received: (kenh at localhost) by elvis.cmf.nrl.navy.mil (8.6.12/8.6.11) id QAA27850; Thu, 26 Sep 2002 16:49:11 -0400
Date: Thu, 26 Sep 2002 16:49:11 -0400
Message-Id: <200209262049.QAA27850 at elvis.cmf.nrl.navy.mil>
To: krb5-bugs at mit.edu
Reply-To: kenh at cmf.nrl.navy.mil
X-send-pr-version: 3.99
X-Spam-Score: hits=2.4 (**)
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.17 (www . roaringpenguin . com / mimedefang)


>Submitter-Id:	net
>Originator:	Ken Hornstein
>Organization:  Naval Research Laboratory
	
>Confidential:	no 
>Synopsis:	Local host login results in host ticket that expires in 5 minutes 
>Severity:	non-critical 
>Priority:	medium 
>Category:	krb5-libs 
>Class:		sw-bug 
>Release:	krb5-1.2.6
>Environment:
System: SunOS elvis 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-1
Architecture: sun4

>Description:
	
I noticed with the new release of Kerberos when doing login to a system using
login.krb5, I get a ticket for my local host that expires in 5 minutes.  This
presents a problem when I want to connect to my local host (which isn't
admittedly normal usage, but it _should_ work, and it used to work just fine).

The reason for this is because krb5_verify_init_creds() gets a service ticket
for the local host, and takes great pains in copying it out to the application;
and then login.krb5 happily writes it to the user's credential cache.
>How-To-Repeat:
	
Login to a machine using login.krb5; do a klist.
>Fix:
It's not clear to me if the right answer is to get a longer ticket from within
verify_init_creds, or just not return it.



More information about the krb5-bugs mailing list