時計が戻ると、Kerberos NFS暗号化が機能しなくなります。

krb5pセキュリティを使用するNFSマウントシステムがあります。時間が後方に移動する場合（数時間程度、正確なしきい値はわからない）を除いて、すべてがうまく機能しているようです。時計が戻ると、マウントを試みると（autofsを使用）、共有は「ファイルまたはディレクトリが存在しません」と報告します。どこかの暗号チェックの1つがリバース時間をチェックして中断されると仮定すると、これは通常のデフォルト動作です。

クライアント/サーバーが同じシステムであり、一部は別のシステムを使用して同じ結果を持つテストケースがあります。すべての時間はNTPを介して同期されます。このテストケースでは、誰もが使用しているNTPサーバーを後ろに移動しました。

わずかに奇妙なテストケースが見つかりましたが、これは完全にオフラインであり、ソフトウェアはオペレータがNTPを正しく設定していないもの（タイプミスなど）など、あらゆる種類の奇妙な入力を処理するように設計されています。これはエッジをテストするだけです。ケース。

時計を現在または将来に戻すと、kdestroy / kinitサイクルの後に共有が再び機能し始めます。

新しいkinitでkdestroyingを試み、sssdキャッシュを消去し、kadmin / k5rb-serverサービスを再起動し、システムを完全に再起動しましたが（/ tmpが破損しています）、何も機能しないようです。

私はシステムに対する完全な制御を持っており、何かを「再インストール」したり、設定/データファイルを消去したりできます。しかし、KerberosまたはNFSが将来の時間があるという事実を忘れてしまうアイテムを保存する場所を見つけることはできません。理論も正確です。）

システム: RHEL7.9

とても感謝しています。

修正する 以下から話題から少し外れたので、時間を逆さまに行くのは変な状況であることを理解していることをはっきりしたいと思います。すべての提案は議論する価値がありますが、この質問はこの状況を処理するためにソフトウェアを修正する方法に焦点を当てています。ハードウェアでこの問題を解決できることを知っていますが、最初に失敗を防ぐ方法（それが言えば）より具体的に失敗する理由と回復方法がより疑問に思います。この極端なケースの可能性を制限するいくつかのハードウェアソリューションがありますが、少なくとも現在のシステム制限でこれをゼロに下げることができるソリューションはなく、残念ながらハードウェアオプションは実現できません。ソフトウェアオプションも実現可能ではないかもしれませんが、理解してみてください。これまで効果があると思われる解決策の1つは、システムのイメージを再作成することですが、あまり大胆でない方法であることを願っています。