ehlo,
I had a discussion with QEs and realized that sssd need to be restarted if default_ccache_name is changed in krb5 configuration files.
The reason is that we cache the value but do not refresh it. https://pagure.io/SSSD/sssd/blob/master/f/src/providers/krb5/krb5_common.c#_...
We might changed that using inotify. But we would need to change. I am not sure whether it will be trivail to change because we would need to change cached value in "struct dp_option *opts" for all domains (including subdomains)
ATM the safest way is to restart sssd. But do we want to be more flexible here?
LS
On Wed, May 31, 2017 at 10:31:38AM +0200, Lukas Slebodnik wrote:
ehlo,
I had a discussion with QEs and realized that sssd need to be restarted if default_ccache_name is changed in krb5 configuration files.
The reason is that we cache the value but do not refresh it. https://pagure.io/SSSD/sssd/blob/master/f/src/providers/krb5/krb5_common.c#_...
We might changed that using inotify. But we would need to change. I am not sure whether it will be trivail to change because we would need to change cached value in "struct dp_option *opts" for all domains (including subdomains)
ATM the safest way is to restart sssd. But do we want to be more flexible here?
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.
On Wed, 2017-05-31 at 10:59 +0200, Jakub Hrozek wrote:
On Wed, May 31, 2017 at 10:31:38AM +0200, Lukas Slebodnik wrote:
ehlo,
I had a discussion with QEs and realized that sssd need to be restarted if default_ccache_name is changed in krb5 configuration files.
The reason is that we cache the value but do not refresh it. https://pagure.io/SSSD/sssd/blob/master/f/src/providers/krb5/krb5_c ommon.c#_264
We might changed that using inotify. But we would need to change. I am not sure whether it will be trivail to change because we would need to change cached value in "struct dp_option *opts" for all domains (including subdomains)
ATM the safest way is to restart sssd. But do we want to be more flexible here?
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.
+1
Simo.
On Wed, May 31, 2017 at 10:31:38AM +0200, Lukas Slebodnik wrote:
ehlo,
I had a discussion with QEs and realized that sssd need to be restarted if default_ccache_name is changed in krb5 configuration files.
The reason is that we cache the value but do not refresh it. https://pagure.io/SSSD/sssd/blob/master/f/src/providers/krb5/krb5_common.c#_...
We might changed that using inotify. But we would need to change. I am not sure whether it will be trivail to change because we would need to change cached value in "struct dp_option *opts" for all domains (including subdomains)
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.
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.
bye, Sumit
LS _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
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.
LS
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@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@lists.fedorahosted.org
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Simo Sorce -
Sumit Bose