-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expired credentials are never renewed #38
Comments
After further investigation... I have two exactly configured services, dovecot and postfix. Postfix seams to renew ticket. As gssproxy is used only to initiate config is converted to:
It seams that dovecot is locking keytab and SELinux is reporting. This should not be problem as SELinux is in permissive mode.
After this sequence nothing changes...Stop service using keytab and make sure nothing is locking keytab.
Remove credentials cache:
Try it using ldapwhoami, gssproxy acquire ticket and everything is working.
After some time when ticket expires it stop working :
Finally I configured gssproxy without client cache file specified:
Removed credentials cache and restarted gssproxy
Try it using ldapwhoami, gssproxy acquire ticket and everything is working.
After some time when ticket expires it continues to work:
ConclusionSo without credentials cache specified everything is working even with dovecot started and locking keytab. I think this issue should be investigated as this should work in original configuration. I'am not sure how to replicate problem as it works with different service identically configured. I'am even not sure if problem lays in MIT kerberos libraries. Maybe gssproxy could check if client cache is valid ie. not been expired before returning. P.S. I forgot to mention gssproxy is version 0.8.4 from Fedora 35 with addition of c6847f0 (Add an option for minimum lifetime) |
The behavior you mention can happen if someone manually primes the ccache instead of letting gssprocy do it via client keytab directives. As for dovecot, you should not give that process direct access to keytab/ccache. The point of gssproxy is to implement privilege separation so that the commanding process can use short term credentials but is not in direct control of the keys. Pretty sure part of your issues will go away if you avoid one interfereing with the other. |
It seams gssproxy doesn't renew client cache on expiration.
If client cache does not exists gssproxy acquire credentials and everything is working until clien cache expires. If client cache files is removed gssproxy acquire new credentials and service using it continues to work.
Service uses SASL GSSAPI to access LDAP and it's running as separate user (1000).
I have tested it with ldapsearch:
sudo -u 1000 GSS_USE_PROXY=yes ldapsearch -Y GSSAPI
klist -c /run/krb5_ccache
that cache is expired.Krb5 trace states
The referenced credential has expired
...BTW. SELinux is in permissive mode.
Service configuration:
Example log with debug_level=3:
The text was updated successfully, but these errors were encountered: