Bug 187485 - Doesn't seem to renew TGT after it has expired
Doesn't seem to renew TGT after it has expired
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: krb5-auth-dialog (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Itamar Reis Peixoto
bzcl34nup
: Triaged
: 234837 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-31 05:19 EST by Colin.Simpson
Modified: 2009-12-18 00:51 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 00:51:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Colin.Simpson 2006-03-31 05:19:31 EST
Description of problem:
The auth diaglog renews the Kerberos tickets usually however if a ticket has
expired (perhaps if it's past it's renewal time I'm unsure it doesn't renew
correctly).

Version-Release number of selected component (if applicable):


How reproducible:
Every time but need to be careful.

Steps to Reproduce:
1. Configured krb5.conf to offer a short term ticket to ease testing. Set
ticket_lifetime = 10m and renew_lifetime = 15m in the libdefaults and pam=
section of krb5.conf.
2. kdestroy and kinit and waited for expire and past renewal time (unsure if
this step is necessary) and waited about 10 mins extra to check. Left
krb5-auth-dialog on screen during expiration period. 
3. After renewal time has passed, typed password into krb5-auth-dialog.
  
Actual results:
Below the old valid TGT but it has now exired as shown by the date command:

[torwood]csimpson: date
Fri Mar 31 10:58:23 BST 2006
[torwood]csimpson: klist
Ticket cache: FILE:/tmp/krb5cc_2000_ZUe7wv
Default principal: csimpson@UNIX.IOUK.IOROOT.TLD

Valid starting     Expires            Service principal
03/31/06 10:32:17  03/31/06 10:42:10 
krbtgt/UNIX.IOUK.IOROOT.TLD@UNIX.IOUK.IOROOT.TLD
        renew until 03/31/06 10:47:10


Kerberos 4 ticket cache: /tmp/tkt2000
klist: You have no tickets cached

Password typed into krb5-auth-diag:

[torwood]csimpson: klist
Ticket cache: FILE:/tmp/krb5cc_2000_ZUe7wv
Default principal: csimpson@UNIX.IOUK.IOROOT.TLD

Valid starting     Expires            Service principal
03/31/06 10:58:16  03/31/06 10:42:47 
krbtgt/UNIX.IOUK.IOROOT.TLD@UNIX.IOUK.IOROOT.TLD
        renew until 03/31/06 10:47:40


Kerberos 4 ticket cache: /tmp/tkt2000
klist: You have no tickets cached

I now seem to have a ticket that expires before it's valid starting date!!
The times of the new TGT seem based on the old ticket times rather than the
current time or something like that.

Typing amother password into krb5-auth-diag continues the problem:
Valid starting     Expires            Service principal
03/31/06 10:59:08  03/31/06 11:08:46 
krbtgt/UNIX.IOUK.IOROOT.TLD@UNIX.IOUK.IOROOT.TLD
        renew until 03/31/06 11:13:46
[torwood]csimpson: date
Fri Mar 31 11:20:28 BST 2006


Expected results:
A new valid TGT.

Additional info:
Comment 1 Colin.Simpson 2007-01-26 07:23:32 EST
krb5-auth-diaglog still seems broken under FC6 (and on our production systems
running RH EL 4 so presumably EL 5 when it appears). The fundamental problem is
that it when it brings up the dialog saying that the credentials have expired it
renews the TGT from the time that that dialog was brought up rather than the
current time. This means that if a TGT expires say in the early evening, the
dialog gets brought up. Then when the user appears in the morning and types in
the password they get a TGT that has already expired. Not so useful. Then
krb5-auth-diag brings up yet another dialog box to renew the expired TGT. 

To reproduce:

% klist
Valid starting     Expires            Service principal
01/26/07 12:02:04  01/26/07 22:02:04 
krbtgt/UNIX.IOUK.IOROOT.TLD@UNIX.IOUK.IOROOT.TLD
        renew until 02/02/07 12:02:04


% kdestroy
(the krb-auth-diag now appear, but leave it for say a minute)

% date
Fri Jan 26 12:17:03 GMT 2007

(type password into krb5-auth-diaglog window)
% klist
Valid starting     Expires            Service principal
01/26/07 12:16:06  01/26/07 22:15:04 
krbtgt/UNIX.IOUK.IOROOT.TLD@UNIX.IOUK.IOROOT.TLD
        renew until 02/02/07 12:15:04

The "Valid starting" time is before current time ie it is set to the time the
dialog came up. In the above example the TGT should start somewhere after 12:17
not 12:16.

Comment 2 Colin.Simpson 2007-03-28 13:03:03 EDT
Since no one is rushing to this one, I've had a look into this myself.

I traced this down to a call to krb5_get_init_creds_password that is
called with the gnome window being the prompter function passed to it.

It turns out kinit behaves this way too.  Obviously not a huge problem for it 
as it isn't run over a long period of time (certianly not like auth-diag is).

So say I have shell1 and shell2 on different terminals. 

shell1% kdestroy
shell1% kinit
Password for csimpson at UNIX.CSL.CO.UK:
shell2% date
Sun Mar 25 12:41:22 BST 2007
(wait for a little while)
shell2%  date
Sun Mar 25 12:42:44 BST 2007
(type password into kinit on shell1)
shell1% klist
Ticket cache: FILE:/tmp/krb5cc_2000_UAdQxX
Default principal: csimpson at UNIX.CSL.CO.UK

Valid starting     Expires            Service principal
03/25/07 12:41:08  03/25/07 22:41:08  krbtgt/UNIX.CSL.CO.UK at UNIX.CSL.CO.UK
	renew until 04/01/07 12:41:08

So I have a TGT valid from the time it prompted and not now. So I presuming 
that krb5_get_init_creds_password goes and gets the TGT before it asks for
the password. I suppose there are valid reasons for this like checking the
principal exists or whether the password has expired before prompting etc. 

Now I posted this query upstream to the MIT krbdev mailing list. 

The one reply I got says,
=========
Don't randomly pop up dialogs that interrupt what the user is doing. 
Ideally, use renewable tickets when possible.  If you're actually going to 
have to interact with the user, provide a visual indication that the 
tickets are expired (for example, something in the notification area), and 
wait for the user to indicate they are ready to renew.

If you really feel you must interrupt the user by popping up a dialog when 
they haven't asked for it, you can work around the problem you described by 
waiting until the terminal is non-idle before doing so.  How to accomplish 
this is left as an exercise for the reader.

-- Jeffrey T. Hutzelman (N3NHS)
=========

Now it would be nice is krb5-auth-diag would check if the ticket is renewable
and if so renew it when it gets near expiring (at least if that behaviour was
flagable)? Any chance.

As to the other point about we shouldn't randomly pop up a dialog bog, he's
perhaps correct. However without fundamentally rewriting krb5-auth-diag to do
this, is another way not to start a timer and if it goes off after say an hour
restart the dialog box so we get a decent length TGT. The timer could be reset
if the box gets typed in (or maybe focused too) so it wouldn't disappear when
someone started typing a password.  A bit of a hack but would fix the problem. I
don't really want to do this myself unless you have no plans to fix this app. 

Comment 3 Christopher Aillon 2007-03-28 15:34:38 EDT
I looked into doing this at one point.  Note that only popping up the dialog
when the user requests is still doesn't really fix the problem as they can still
leave it up for a long time before entering their credentials even though it is
less likely to happen.

I then looked into creating a dialog via GTK+, and not going via the krb5
prompter methods, but the problem is that kerberos doesn't provide an API to
know whether to login via smartcard or password or other means, so I can't
accurately say "please enter your krb5 password" or "please enter your smartcard
PIN".

I spoke with Nalin, our kerberos developer a few months back and he said he was
going to look into updating the timestamp for the request right before the
password was sent.  Copying him for extra feedback.

An additional note though is that krb5-auth-dialog _does_ support renewable
credentials already, which should help if you configure your setup to use them.
 It won't pop up anything in this case and simply renew the ticket automatically
for you.
Comment 4 Nalin Dahyabhai 2007-03-28 15:53:18 EDT
Chris, didn't we already have renewing-if-renewable functionality?

To answer your other question, changing the start-time in the AS request right
before we transmit it isn't a workable option because preauthentication may
involve generating a signature over the request body as it existed while we were
prompting the user for information (for example, PKINIT), and mucking around
with the request contents would totally break that.
Comment 5 Colin.Simpson 2007-03-30 13:48:17 EDT
So where should this app go from here, it's very confusing the way it operates
just now in that it looks like it's failed to the user when. How about the timer
idea I had as a hack , to reset the diag window after say an hour. 
Comment 6 Christopher Aillon 2007-03-30 13:50:39 EDT
Yeah it already has renewing functionality.  Preferably kerberos setups would
use that.

I suppose I'll resurrect my work for the systray stuff and rip out the pieces
that would break the prompt.  Probably not until next weekend though as I'm sort
of strapped this weekend with other stuff.
Comment 7 Colin.Simpson 2007-03-30 14:06:09 EDT
We do issue tickets that are renewable, however some of our users manage to stay
logged in for longer than the renewable time of 7 days. Thanks for your help on
this.
Comment 8 Bug Zapper 2008-04-03 22:24:31 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 9 Colin.Simpson 2008-04-04 04:36:59 EDT
It's still in Fedora 8 and RH5. SO I guess still a bug unless this has changed in 
F9. Someone earlier said they'd work on it the following weekend, a year a
ago...I know priorities etc....

Comment 10 J. Bruce Fields 2008-09-02 11:06:53 EDT
I can confirm it's still in FC9.
Comment 11 John Poelstra 2008-09-02 14:44:43 EDT
changing version to 9 based on comment #10
Comment 12 Bojan Smojver 2008-09-08 01:55:10 EDT
> The fundamental problem is that it when it brings up the dialog saying that the credentials have expired it renews the TGT from the time that that dialog was brought up rather than the current time.

I'm seeing this a lot post thaw/resume. It picks up the old time and the ticket ends up with the time that's too skewed to be useful.

Maybe the tool should check if ntpd is configured on the box and if it is wait until the time is synced from the server before renewing? Also, clock script  /usr/lib/pm-utils/sleep.d/90clock has a delay of 20 seconds (for the network to come up). Maybe this tool should have a longer delay on thaw/resume to allow for all this to happen?
Comment 13 Fedora Admin XMLRPC Client 2009-02-09 13:45:19 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Patrick C. F. Ernzer 2009-02-11 15:00:59 EST
*** Bug 234837 has been marked as a duplicate of this bug. ***
Comment 15 Bug Zapper 2009-06-09 18:07:56 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Colin.Simpson 2009-06-10 05:12:02 EDT
I've changed to F10 as it's still in there, haven't tried F11 yet.
Comment 17 Matěj Cepl 2009-06-13 01:54:07 EDT
New upgrade of krb5-auth-dialog was provided as https://admin.fedoraproject.org/updates/krb5-auth-dialog-0.10-1.fc11, which may affect this bug.

Please retest and let us know, whether you can still reproduce this bug.
Comment 18 Colin.Simpson 2009-06-16 05:26:02 EDT
The krb5-auth-dialog-0.10-1.fc11 does seem to work more cleanly. Even though if you bring the password dialog and leave it there it still just gets a ticket from when the dialog was brought up, this is massively mitigated by it grabbing the keyboard so the user has to pretty much complete this operation (I guess your intention with this implementation). So should fix the original problem, great stuff! 

One minor wrinkle I noticed was if you leave the password dialog up, it seems to prevent the screen saver running (gnome-screensaver). I presume as it's grabbed the keyboard, there may not be a good way around that. (still don't know why gnome-screen saver's password dialog doesn't renew the TGT, given that you are giving it a password that is check in Kerberos)
Comment 19 Petter Urkedal 2009-06-23 04:51:18 EDT
(In reply to comment #18)
> One minor wrinkle I noticed was if you leave the password dialog up, it seems
> to prevent the screen saver running (gnome-screensaver). I presume as it's
> grabbed the keyboard, there may not be a good way around that. (still don't
> know why gnome-screen saver's password dialog doesn't renew the TGT, given that
> you are giving it a password that is check in Kerberos)  

Assuming the TGT renewal works in gnome-screensaver (which it does for me on
EL5), I think the ideal behaviour here is that krb5-auth-dialog closes its
window when the screen saver triggers, and that it doesn't open any windows
as long as the screen saver is active.

This (different) fix from Ubuntu may be of interest:
https://bugs.launchpad.net/ubuntu/+source/krb5-auth-dialog/+bug/73550
Comment 20 Bojan Smojver 2009-06-23 07:29:52 EDT
Regarding comment #18:

> still don't know why gnome-screen saver's password dialog doesn't renew the TGT, given that you are giving it a password that is check in Kerberos

Gnome screensaver is relying on PAM for authentication. Whatever pam_krb5 does, that is what happens. Try this:

kinit -l 10s -r 10s

In 10 seconds, your ticket will expire. Do:

tail -f /var/log/secure

In a terminal. Also, watch the tickets with:

watch klist 2>/dev/null

Now, lock the screen. Unlock and you'll see messages like this in secure log:

Jun 23 21:23:08 machine gnome-screensaver-dialog: pam_krb5[27056]: authentication succeeds for 'bojan' (bojan@REALM.COM)

However, the ticket times will not move (ie. the ticket will not be reissued).

So, this is something that pam_krb5 does or doesn't do, I think. Maybe PAM folks should change something?
Comment 21 Bojan Smojver 2009-06-23 07:40:18 EDT
Maybe bug #187341?
Comment 22 Bojan Smojver 2009-06-23 07:55:12 EDT
Hmm, interesting... Strace of gnome-screensaver on lock/unlock doesn't show any file named /tmp/krb5cc_* being opened.
Comment 23 Colin.Simpson 2009-06-23 10:05:22 EDT
The bug in gnome-screensaver was fixed in RH in my bug #187341. However that bug does appear to be again present in later Fedora distro's, I've just tried F11 and the gnome-screensaver neither renews an expired TGT, renews a current TGT or renews a nonexistent TGT. Even though it takes my Kerberos password to unlock the screen saver.
Comment 24 Bojan Smojver 2009-06-23 21:51:47 EDT
Here is a bit of code from gnome-screensaver (src/gs-auth-pam.c):
----------------------
       /* Each time we successfully authenticate, refresh credentials,
           for Kerberos/AFS/DCE/etc.  If this fails, just ignore that
           failure and blunder along; it shouldn't matter.

           Note: this used to be PAM_REFRESH_CRED instead of
           PAM_REINITIALIZE_CRED, but Jason Heiss <jheiss@ee.washington.edu>
           says that the Linux PAM library ignores that one, and only refreshes
           credentials when using PAM_REINITIALIZE_CRED.
        */
        status2 = pam_setcred (pam_handle, PAM_REINITIALIZE_CRED);
        if (gs_auth_get_verbose ()) {
                g_message ("   pam_setcred (...) ==> %d (%s)",
                           status2,
                           PAM_STRERROR (pam_handle, status2));
        }
----------------------

Not sure if the fact that we don't care about credentials being refreshed above matters or not.
Comment 25 Bojan Smojver 2009-06-24 00:12:12 EDT
I tried this patch with gnome-screensaver:
-----------------------------
--- a/src/gs-auth-pam.c
+++ b/src/gs-auth-pam.c
@@ -545,15 +545,11 @@ gs_auth_thread_func (int auth_operation_fd)
         }
 
         /* Each time we successfully authenticate, refresh credentials,
-           for Kerberos/AFS/DCE/etc.  If this fails, just ignore that
-           failure and blunder along; it shouldn't matter.
-
-           Note: this used to be PAM_REFRESH_CRED instead of
-           PAM_REINITIALIZE_CRED, but Jason Heiss <jheiss@ee.washington.edu>
-           says that the Linux PAM library ignores that one, and only refreshes
-           credentials when using PAM_REINITIALIZE_CRED.
+           for Kerberos/AFS/DCE/etc. Use PAM_ESTABLISH_CRED to get new
+           ticket.
         */
-        status2 = pam_setcred (pam_handle, PAM_REINITIALIZE_CRED);
+        status2 = pam_setcred (pam_handle, PAM_DELETE_CRED);
+        status2 = pam_setcred (pam_handle, PAM_ESTABLISH_CRED);
         if (gs_auth_get_verbose ()) {
                 g_message ("   pam_setcred (...) ==> %d (%s)",
                            status2,
-----------------------------

However, this creates _another_ ticket - doesn't replace the existing one. In any event, PAM_REINITIALIZE_CRED doesn't appear to do anything to the ticket at all. Hmm, weird...

I even tried setting KRB5CCNAME before running gnome-screensaver, but that didn't do anything either. Probably because the environment passed to the libexec program in question didn't pass it along or something.

Anyhow, I'll stop now - somebody actually familiar with this code should have a look.
Comment 26 Bojan Smojver 2009-06-24 02:49:43 EDT
Interesting text in this document:

http://www.freeipa.org/page/Automatic_Ticket_Renewal

-------------------------
Another factor to keep in mind is that in normal circumstances the user can obtain a completely new ticket simply performing an authentication. A common method to force a new authentication is to lock the machine and provide the user password to the screensaver. This will generate a new PAM authentication which will allow us to obtain a completely new TGT extending renewal time to 14 days from that point on.
-------------------------

Except that the screensaver doesn't do that :-(
Comment 27 Bojan Smojver 2009-06-24 04:56:11 EDT
In reply to comment #25:

> Probably because the environment passed to the
> libexec program in question didn't pass it along or something.

In fact, this environment variable makes it all the way to spawn_on_window() function just fine. Probably something in pam_krb5 after all...
Comment 28 Bojan Smojver 2009-06-24 19:37:19 EDT
Another interesting test with pam_krb5. It provides a little test program called harness in the src directory, which exercises pam_krb5 machinery. When this program is run like this:

src/harness --auth --setcred-reinitialize

It will actually reissue the ticket if KRB5CCNAME is set to the correct credentials cache file (usuallly /tmp/krb5cc_`id -u`). If that environment variable is not set, nothing happens to the ticket.

I have no idea why gnome-screensaver has no luck doing that when KRB5CCNAME is set, given it's essentially using the same PAM API calls. Weird...

BTW, this should work even when KRB5CCNAME is _not_ set in pam_krb5: default ticket should be reinitialised by default. I'll try to contact pam_krb5 developer to see if it can be changed.
Comment 29 Bojan Smojver 2009-06-24 23:14:35 EDT
For a patch to pam_krb5 that enables gnome-screensaver to obtain a new ticket on unlocking, see bug #507984. Not sure if it is correct, but I'm sure pam_krb5 maintainer will let us know.
Comment 30 Bojan Smojver 2009-06-25 04:41:52 EDT
Regarding comment #25:

> I even tried setting KRB5CCNAME before running gnome-screensaver,
> but that didn't do anything either.

Not actually true. It does work when this is set.
Comment 31 Bug Zapper 2009-11-18 03:06:15 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Bug Zapper 2009-12-18 00:51:49 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.