并行kinit调用导致Kerberos缓存损坏。

Question

如果我多次尝试并行使用Kerberos键签进行身份验证，则会随机获得错误消息，说明凭据缓存已损坏。

我可以用下面的脚本来重现这个问题。但是，在我的实际用例中，有同时调用kinit的进程，而我无法控制它们：

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"

每次运行它都会产生随机输出。这种输出的一个例子如下：

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“等待轮到它”，如果缓存已经被另一个进程访问了，就不要访问它？

Answer 1

如果多个进程独立创建票证，那么它们就没有理由使用相同的凭据缓存。在最坏的情况下，他们甚至会使用不同的原则，副作用是.有意思的。

解决方案:更改每个进程的环境，以便KRB5CCNAME指向特定的文件--最好是在应用程序特定的目录中。这样就能防止比赛，收拾你的烂摊子。

部分解决方案:维护单个缓存，但不基于文件(因为Linux无法强制文件上的独占锁)，例如KEYRING。

不管怎么说，你有权抱怨.呃，这些应用程序开发的笨拙的方式。或者它们被设计成在孤立的容器中运行？

Answer 2

在我们的例子中，我们必须使用相同的进程执行并发作业。最后，使用外部文件锁来同步并行kinit调用。

Begin
…

#Assign unused file descriptor e.g. 99 to a file called “kinit_lock.dat”
exec 99 >”kinit_lock.dat”

#try to acquire exclusive lock for “kinit_lock.dat” with timeout of 5 secs.
flock -x -w 5 99

#Invoke kinit
kinit <parameters>

#unlock the kinit lock file
flock -u 99

…
Job script
…

End