On Wed, May 31, 2017 at 02:21:42PM +0200, Lukas Slebodnik wrote:
On (31/05/17 10:59), Jakub Hrozek wrote:
>We could do one thing that Simo proposed some time ago which is to not
>cache the KRB5CCNAME at all if it only contains 'predictable'
>components.
>
>For example, KEYRING:$uid or KCM: don't need to be cached at all.
>FILE:krb5ccname_XXXXX does.
That would still not solve that value is cached and not reload :-)
On (31/05/17 13:50), Sumit Bose wrote:
>A more simple approach might be to call sss_get_system_ccname_template()
>in krb5_auth_prepare_ccache_name() are read the value for every
>authentication or try to move all of this to krb5_child which always
>reads the current krb5.conf.
>
There are more options how to solve it.
>> ATM the safest way is to restart sssd. But do we want to be more flexible here?
>
>I just checked with sshd and delegation and it looks like sshd picks up
>the changes without a restart because the forked sshd child will call
>krb5_init_context() for each new connection. So I think it would be nice
>if SSSD can respect the change as will without restart. But I do not
>consider this an urgent issue.
>
But it looks lie we agreed that it should be fixed.
If there won't be any objections in few days I will file a ticket.
yes.
another execercise for us would be -- have an upstream milestone that
corresponds to f-27 esp if we want to default to kcm..
>
> LS
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org