Skip Menu |
 

Download (untitled) / with headers
text/plain 4.1KiB
From krb5-bugs-incoming-bounces@PCH.mit.edu Fri Mar 12 17:09:51 2010
Return-Path: <krb5-bugs-incoming-bounces@PCH.mit.edu>
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by krbdev.mit.edu (Postfix) with ESMTP id 753203F0F7;
Fri, 12 Mar 2010 17:09:51 -0500 (EST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o2CM9pSm013892;
Fri, 12 Mar 2010 17:09:51 -0500
Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o2CKW0n0031509
for <krb5-bugs-incoming@PCH.mit.edu>; Fri, 12 Mar 2010 15:32:00 -0500
Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU
[18.9.25.12])
by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o2CKVvfx006227
for <krb5-bugs@mit.edu>; Fri, 12 Mar 2010 15:32:00 -0500
X-AuditID: 1209190c-b7c8cae00000610c-36-4b9aa4bf4a45
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with
SMTP id AD.05.24844.0C4AA9B4; Fri, 12 Mar 2010 15:32:00 -0500 (EST)
Received: from int-mx08.intmail.prod.int.phx2.redhat.com
(int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21])
by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2CKVxS6032099
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for <krb5-bugs@mit.edu>; Fri, 12 Mar 2010 15:31:59 -0500
Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.0.23])
by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id o2CKVvjt024940
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <krb5-bugs@mit.edu>; Fri, 12 Mar 2010 15:31:58 -0500
Received: from blade.bos.redhat.com (localhost [127.0.0.1])
by blade.bos.redhat.com (8.14.4/8.14.3) with ESMTP id o2CKVuIQ023042
for <krb5-bugs@mit.edu>; Fri, 12 Mar 2010 15:31:56 -0500
Received: (from nalin@localhost)
by blade.bos.redhat.com (8.14.4/8.14.4/Submit) id o2CKVuAe023041;
Fri, 12 Mar 2010 15:31:56 -0500
Date: Fri, 12 Mar 2010 15:31:56 -0500
Message-Id: <201003122031.o2CKVuAe023041@blade.bos.redhat.com>
To: krb5-bugs@mit.edu
Subject: krb5_get_init_creds_password() is inconsistent about when it warns
about impending expiration
From: nalin@redhat.com
X-send-pr-version: 3.99
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21
X-Brightmail-Tracker: AAAAAhM9I9YTPgcy
X-Mailman-Approved-At: Fri, 12 Mar 2010 17:09:50 -0500
X-BeenThere: krb5-bugs-incoming@mailman.mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: nalin@redhat.com
Sender: krb5-bugs-incoming-bounces@PCH.mit.edu
Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu


Show quoted text
>Submitter-Id: net
>Originator: Nalin Dahyabhai
>Organization:
>Confidential: no
>Synopsis: krb5_get_init_creds_password() is inconsistent about when it warns about impending expiration
>Severity: non-critical
>Priority: low
>Category: krb5-libs
>Class: change-request
>Release: 1.8
>Environment:

System: Linux blade.bos.redhat.com 2.6.31.9-174.fc12.x86_64 #1 SMP Mon Dec 21 05:33:33 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64

Show quoted text
>Description:
When the date of expiration for the user's keys is relayed to the
client from the KDC using the kex_exp field in the AS reply,
krb5_get_init_creds_password() only prints a warning if it's less than
a week from now. When the same information is returned as part of the
last_req data, the client doesn't put an upper limit on the amount of
time left before it will start printing a warning, even if the
expiration date is months from now.
Show quoted text
>Fix:
Here's a patch to make the behavior consistent:

Index: src/lib/krb5/krb/gic_pwd.c
===================================================================
--- src/lib/krb5/krb/gic_pwd.c (revision 23799)
+++ src/lib/krb5/krb/gic_pwd.c (working copy)
@@ -403,7 +403,8 @@
delta / 86400, ts);
/* ignore an error here */
/* PROMPTER_INVOCATION */
- (*prompter)(context, data, 0, banner, 0, 0);
+ if (delta < (60 * 60 * 24 * 7))
+ (*prompter)(context, data, 0, banner, 0, 0);
}
}
}
Per the log message for r14936, this is intentional behavior:

---
Note that the intent is that the last-req type will only be included by
the KDC when the time until password expiration reaches some threshold
(e.g, one week), so this code will display the password expiration
anytime the last-req type is included.
---

(A classic case of "code documentation belongs in comments, not commit
logs.")

Now, I don't know if that statement reflects reality. Allowing the KDC
to control when expiration notification happens seems well and fine, but
RFC 4120 doesn't appear to say that last-req expiration times should be
used that way.