GNOME Bugzilla – Bug 796095
Kerberos tickets not refreshed on resume
Last modified: 2019-01-17 11:43:23 UTC
Whenever my PC resumes from standby on mornings, my Kerberos tickets are usually expired. I think this hasn't been working for a long time, but in 3.27/3.28 I'm at least getting error messages on resume: goa-identity-se[1130]: GoaAlarm: failed to read from timer fd: Error reading from file descriptor: Operation canceled gnome-online-accounts 3.28.0
Created attachment 372033 [details] [review] GoaAlarm: Continue firing on ECANCELED from timerfd A read() from the timerfd will return G_IO_ERROR_CANCELLED when the clock jumps, e.g. when the system time is set or the system wakes from suspend (see man 2 timerfd_create). In this case, instead of giving up on firing completely, continue on to call fire_or_rearm_alarm. This should be the right thing to do.
Please review.
Review of attachment 372033 [details] [review]: Thanks for figuring this out, and sorry for the long delay in getting round to this. From the looks of it, this does look like the right thing to do. I will test this across a suspend-resume cycle today before merging it.
@halfline: does this look OK to you?
I reproduced this overnight with a KCM credential cache. After resuming from suspend I did get the "failed to read from timer fd" in my logs and my tickets were expired. However, a few minutes later I noticed that I have new tickets in my cache. I wonder if that was some trick performed by the KCM cache. Being backed by SSSD, I think it has some smarts built into it, unlike DIR, FILE or KEYRING, which are passive entities. Right after resumption: $ klist -A Ticket cache: KCM:1000:14945 Default principal: rishi@FEDORAPROJECT.ORG Valid starting Expires Service principal 2018-11-21T10:37:49 2018-11-22T10:37:48 krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG renew until 2018-11-28T10:37:49 Ticket cache: KCM:1000 Default principal: dray@REDHAT.COM Valid starting Expires Service principal 2018-11-21T18:43:14 2018-11-22T04:43:14 krbtgt/REDHAT.COM@REDHAT.COM renew until 2018-11-28T18:43:14 A minute or two later: $ klist -A Ticket cache: KCM:1000:14945 Default principal: rishi@FEDORAPROJECT.ORG Valid starting Expires Service principal 2018-11-22T15:31:27 2018-11-23T15:31:26 krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG renew until 2018-11-29T15:31:27 Ticket cache: KCM:1000 Default principal: dray@REDHAT.COM Valid starting Expires Service principal 2018-11-22T15:31:28 2018-11-23T01:31:28 krbtgt/REDHAT.COM@REDHAT.COM renew until 2018-11-29T15:31:28
Created attachment 374161 [details] [review] alarm: Refresh Kerberos tickets after a suspended system is resumed Rebased against master. I tweaked the debug message to mention "timer fd", and added the user visibile effect to the commit message.
makes sense to me
Ok, thanks Ray. The tickets on my KEYRING cache are about to expire, and I am going to test the fix on both KCM and KEYRING after that. Once that's done, I will merge it. For context, grawity has FILE caches and heftig managed to fix this blindly without even using Kerberos (wow!). Hence my insistence on reproducing the problem and testing the fix.
KEYRING caches are also able to recover a few minutes after resumption, even though I get the "failed to read from timer fd" in my logs. Right after resumption: $ klist -A $ A minute or two later: $ klist -A Ticket cache: KEYRING:persistent:1000:1000 Default principal: rishi@FEDORAPROJECT.ORG Valid starting Expires Service principal 2018-11-23T21:52:28 2018-11-24T21:52:27 krbtgt/FEDORAPROJECT.ORG@FEDORAPROJECT.ORG renew until 2018-11-30T21:52:28 It might be that DIR and FILE caches are the only ones that actually fail to refresh the credentials. In that case it might be related to the fact that DIR and FILE caches notify us of changes through inotify(7) while for KEYRING and KCM we poll the cache.
It turns out that this patch does make a difference if there's a change in network across the suspend-resume cycle. eg., Tomas tested this with a KCM cache. Earlier, if he had suspended on a network where the KDC wasn't reachable and resumed on one where it was, his tickets wouldn't be refreshed, but with this patch, it works.
Pushed to master, gnome-3-30, and gnome-3-28, and rolled tarballs for the stable branches. Thanks everybody!