On 01/15/2013 11:55 PM, Simo Sorce wrote:
On Tue, 2013-01-15 at 17:36 -0500, Dmitri Pal wrote:
On 01/15/2013 03:59 PM, Simo Sorce wrote:
On Tue, 2013-01-15 at 15:53 -0500, Rob Crittenden wrote:
Dmitri Pal wrote:
On 01/15/2013 08:48 AM, Simo Sorce wrote:
On Mon, 2013-01-14 at 16:46 +0100, Tomas Babej wrote:
Hi,

Since in Kerberos V5 are used 32-bit unix timestamps, setting
maxlife in pwpolicy to values such as 9999 days would cause
integer overflow in krbPasswordExpiration attribute.

This would result into unpredictable behaviour such as users
not being able to log in after password expiration if password
policy was changed (#3114) or new users not being able to log
in at all (#3312).

https://fedorahosted.org/freeipa/ticket/3312
https://fedorahosted.org/freeipa/ticket/3114
Given that we control the KDC LDAP driver I think we should not limit
the time in LDAP but rather 'fix-it-up' for the KDC in the DAL driver.
Fix how? Truncate to max in the driver itself if it was entered beyond max?
Shouldn't we also prevent entering the invalid value into the attribute?

I've been mulling the same question for a while. Why would we want to
let bad data get into the directory?
It is not bad data and the attribute holds a Generalize time date.

The data is valid it's the MIT code that has a limitation in parsing it.

Greg tells me he plans supporting additional time by using the
'negative' part of the integer to represent the years beyond 2038.

So we should represent data in the directory correctly, which means
whtever date in the future and only chop it when feeding MIT libraries
until they support the additional range at which time we will change and
chop further in the future (around 2067 or so).

If we chopped early in the directory we'd not be able to properly
represent/change rapresentation later when MIT libs gain additional
range capabilities.

Simo.

We would have to change our code either way and the amount of change
will be similar so does it really matter?
Yes it really matters IMO.

Simo.

Updated patch attached.

Tomas
>From 61b27c5eeea587a5455aa74cf72511c9a5c8d0c0 Mon Sep 17 00:00:00 2001
From: Tomas Babej <tba...@redhat.com>
Date: Mon, 14 Jan 2013 10:19:44 -0500
Subject: [PATCH] Prevent integer overflow when setting krbPasswordExpiration

Since in Kerberos V5 are used 32-bit unix timestamps, setting
maxlife in pwpolicy to values such as 9999 days would cause
integer overflow in krbPasswordExpiration attribute.

This would result into unpredictable behaviour such as users
not being able to log in after password expiration if password
policy was changed (#3114) or new users not being able to log
in at all (#3312).

The timestamp value is truncated to Jan 1, 2038 in ipa-kdc driver.

https://fedorahosted.org/freeipa/ticket/3312
https://fedorahosted.org/freeipa/ticket/3114
---
 daemons/ipa-kdb/ipa_kdb_passwords.c | 5 +++++
 util/ipa_pwd.h                      | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/daemons/ipa-kdb/ipa_kdb_passwords.c b/daemons/ipa-kdb/ipa_kdb_passwords.c
index b6520ea75a78474f6f7761311c9d165924e88b27..d42db1ee862c5d2a912ff9af3025e264d2656ff4 100644
--- a/daemons/ipa-kdb/ipa_kdb_passwords.c
+++ b/daemons/ipa-kdb/ipa_kdb_passwords.c
@@ -246,6 +246,11 @@ krb5_error_code ipadb_get_pwd_expiration(krb5_context context,
         *expire_time = mod_time;
     }
 
+    /* in the case of integer owerflow, set expiration to IPAPWD_END_OF_TIME */
+    if ((*expire_time+86400) < mod_time) {
+        *expire_time = IPAPWD_END_OF_TIME; // 1 Jan 2038, 00:00 GMT
+    }
+
     kerr = 0;
 
 done:
diff --git a/util/ipa_pwd.h b/util/ipa_pwd.h
index 00de889ff53cdc113a6c926e35c87e7b08238e4a..a6990cac6333bf2582fb071a507001b10145df6d 100644
--- a/util/ipa_pwd.h
+++ b/util/ipa_pwd.h
@@ -27,6 +27,9 @@
 #define IPAPWD_DEFAULT_PWDLIFE (90 * 24 *3600)
 #define IPAPWD_DEFAULT_MINLEN 0
 
+/* 1 Jan 2038, 00:00 GMT */
+#define IPAPWD_END_OF_TIME 2145916800
+
 /*
  * IMPORTANT: please update error string table in ipa_pwd.c if you change this
  * error code table.
-- 
1.8.0.2

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to