Am Mon, Mar 03, 2025 at 02:57:16PM +0200 schrieb Alexander Bokovoy: > On Пан, 03 сак 2025, Winfried de Heiden via FreeIPA-users wrote: > > Hi all, > > > > It seems we hit a "year 2038" related problem in the IPA-client > > (krb5_child). We're using IPA for service accounts and to be shure these > > accounts will not expire, we created a password policy: > > > > ipa pwpolicy-show service_accounts > > Group: service_accounts > > Max lifetime (days): 9999 > > ... > > > > To be on the safe site, the max life time is set to 9999 days. That's > > well beyond 19 January 2038 03:14:07 UTC... > > > > Now, in case a service accounts will login, the krb5_child.log on the > > IPA client will show errors like: > > > > (2025-03-03 11:55:12): [krb5_child[2058626]] > > [sss_krb5_expire_callback_func] (0x0020): [RID#5037] Time to expire out > > of range. > > ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING > > BACKTRACE: > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [main] (0x0400): > > [RID#5037] krb5_child started. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [unpack_buffer] > > (0x1000): [RID#5037] total buffer size: [144] > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [unpack_buffer] > > (0x0100): [RID#5037] cmd [241 (auth)] uid [100045] gid [100045] validate > > [true] enterprise principal [false] offline [false] UPN > > [[email protected]] > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [unpack_buffer] > > (0x0100): [RID#5037] ccname: [KCM:] old_ccname: [KCM:] keytab: > > [/etc/krb5.keytab] > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [switch_creds] > > (0x0200): [RID#5037] Switch user to [100045][100045]. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [switch_creds] > > (0x0200): [RID#5037] Switch user to [0][0]. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] > > [k5c_check_old_ccache] (0x4000): [RID#5037] Ccache_file is [KCM:] and is > > not active and TGT is valid. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] > > [k5c_precreate_ccache] (0x4000): [RID#5037] Recreating ccache > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [k5c_setup_fast] > > (0x0100): [RID#5037] Fast principal is set to > > [host/[email protected]] > > * (2025-03-03 11:55:12): [krb5_child[2058626]] > > [find_principal_in_keytab] (0x4000): [RID#5037] Trying to find principal > > host/[email protected] in keytab. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [match_principal] > > (0x1000): [RID#5037] Principal matched to the sample > > (host/[email protected]). > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [check_fast_ccache] > > (0x0200): [RID#5037] FAST TGT is still valid. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [become_user] > > (0x0200): [RID#5037] Trying to become user [100045][100045]. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [main] (0x2000): > > [RID#5037] Running as [100045][100045]. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] > > [set_lifetime_options] (0x0100): [RID#5037] No specific renewable > > lifetime requested. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] > > [set_lifetime_options] (0x0100): [RID#5037] No specific lifetime > > requested. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] > > [set_canonicalize_option] (0x0100): [RID#5037] Canonicalization is set > > to [true] > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [main] (0x0400): > > [RID#5037] Will perform auth > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [main] (0x0400): > > [RID#5037] Will perform online auth > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [tgt_req_child] > > (0x1000): [RID#5037] Attempting to get a TGT > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [get_and_save_tgt] > > (0x0400): [RID#5037] Attempting kinit for realm [SOME-DOMAIN.LAN] > > * (2025-03-03 11:55:12): [krb5_child[2058626]] [sss_krb5_responder] > > (0x4000): [RID#5037] Got question [password]. > > * (2025-03-03 11:55:12): [krb5_child[2058626]] > > [sss_krb5_expire_callback_func] (0x0020): [RID#5037] Time to expire out > > of range. > > This looks like a bug in SSSD code as it doesn't support krb5_timestamp > trick to go beyond Y2038: > > exp_time = password_expiration - time(NULL); > if (exp_time < 0 || exp_time > UINT32_MAX) { > DEBUG(SSSDBG_CRIT_FAILURE, "Time to expire out of range.\n"); > return; > }
Hi, thanks for catching this, the SSSD code was written before https://krbdev.mit.edu/rt/Ticket/Display.html?id=8352 was fixed and I guess we hadn't checked the implications so far. Please open a ticket at https://github.com/SSSD/sssd/issues/new to fix this. bye, Sumit > > krb5 uses unsigned time_t representation these days: > > For 32-bit unsigned time values starting on 1/1/1970, the range is: > * time 0x00000000 -> Thu Jan 1 00:00:00 1970 > * time 0xffffffff -> Sun Feb 7 06:28:15 2106 > > Basically, SSSD code needs to cast krb5_timestamp to uint32_t first and > then perform its operations. > > > > ********************** BACKTRACE DUMP ENDS HERE > > ********************************* > > > > Doing some more testing: > > > > ipa user-mod some_service_account --password-expiration='2038-01-19 > > 03:14:06Z' --> de errors will disappear (one second before the > > "Epochalypse") > > > > ipa user-mod some_service_account --password-expiration='2038-01-19 > > 03:14:08Z' --> the error returns! (one second after the "Epochalypse") > > > > For now, setting the expiry date below January 19 2038 is OK, but it > > smells like a bug, doesn't it...? > > Should a bug report created on this topic? Where? > > > > Kind regards, > > > > Winfried > > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
