URL:
https://github.com/SSSD/sssd/pull/5450
Title: #5450: kcm: add support for kerberos tgt renewals
pbrezina commented:
"""
There are few minor comments... but:
If I understand it correctly, this functionality requires KCM to be running. KCM is
currently socket activated so I see two problems:
1. Unless somebody use Kerberos regularly, keeping the KCM busy, the renewal will not
work. So this makes the feature unfortunately useless, since you want to renew the ticket
mostly when you don't use the computer for longer period of times, e.g. when you have
session locked during a weekend.
* the timer will be always scheduled in a destined future time when KCM is
started, but KCM will likely terminate before we get even close to this time (idle timeout
is five minutes).
2. You add creds to renew table on two places:
a) when KCM process starts `kcm_process_init`
b) when renew timer is triggers `kcm_renew_tgt_timer_handler`
However, since it is socket activated, b) is very unlikely to happen. And we
already have performance issues so its probably not a very good idea to do it in a).
The code itself is fine, but unless I am missing something, it is currently unusable. We
have to either avoid socket activation, which is not desirable. Or find a way how to
execute the process periodically in certain intervals (systemd timer might help here) and
change the renew table logic.
Ah, I missed the last patch: `KCM: Disable responder idle timeout with renewals`. So it
will work correclty. But I wonder if it would be better to keep the idle timeout enabled.
What we could do is to make systemd timer send a SSSD-specific KCM op code periodically
and renew the tickets per-request. This would also simplify the logic by a lot since you
would not have to keep the hash table and timers.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/5450#issuecomment-799333755