并行kinit调用导致Kerberos缓存损坏 [英] Parallel kinit calls lead to a corrupted Kerberos cache

查看:960
本文介绍了并行kinit调用导致Kerberos缓存损坏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果我尝试并行使用Kerberos keytab进行多次身份验证,则会随机收到错误消息,指出凭据缓存已损坏.

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.

我可以使用以下脚本重现此问题.但是,在我的实际用例中,有多个进程同时调用kinit,而我无法控制它们:

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

是否有一种方法可以使kinit等待轮到它"并且如果另一个进程已经在访问该缓存,则不访问该缓存?

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.

解决方案:更改每个进程的环境,以使KRB5CCNAME指向特定文件-最好指向特定于应用程序的目录.这样可以防止出现比赛情况,并清理您的烂摊子.

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.

部分解决方案:维护单个缓存,但不基于文件(因为Linux无法对文件强制执行排他锁定),例如KEYRING.

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 ?

这篇关于并行kinit调用导致Kerberos缓存损坏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆