If I try to authenticate with a Kerberos keytab multiple times in parallel, I randomly get error messages stating that the credentials cache is corrupted.
I could reproduce this problem with the following script. However, in my real use case there are processes calling kinit at the same time and I cannot control them :
kdestroy
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK" &
kinit $USER@$REALM -k -t $HOME/$USER.keytab && echo "OK"
Which produces random outputs each time I run it. An example of such an output is as follows :
kinit: Failed to store credentials: Internal credentials cache error (filename: /tmp/krb5cc_1645005342) while getting initial credentials
kinit: Failed to store credentials: No credentials cache found (filename: /tmp/krb5cc_1645005342) while getting initial credentials
kinit: Failed to store credentials: Bad format in credentials cache (filename: /tmp/krb5cc_1645005342) while getting initial credentials
OK
OK
Is there a way to make kinit "wait its turn" and don't access the cache if it is already being accessed by another process ?
If multiple processes create tickets independently, then they have no reason to use the same credentials cache. In the worst case they would even use different principals, and the side effects would be... interesting.
Solution: change the environment of each process so that KRB5CCNAME points to a specific file -- and preferably, in an application-specific directory. That will prevent race conditions, and clean up your mess.
Partial solution: maintain a single cache, but not based on a file (since Linux has no way to force an exclusive lock on a file) e.g. KEYRING.
Anyway you are entitled to complain about the sh... er, the clumsy way these apps have been developed. Or maybe they were designed to run in isolated containers ?