鍵の前に各ディレクトリの検索権限を確認する

0600 というモードと正しい所有者だけでは、サービスが鍵を開ける保証にはなりません。足りない権限は、たいていその上のディレクトリにあります。Linux は経路を一つの構成要素ずつ解決し、各段階で次の試行の前に検索権限が必要です。一覧の最終行ではなく、経路全体を読んでください。

読み取り権限は最後の段階であり、唯一の段階ではない

ファイルを開くには、カーネルがルートまたは作業ディレクトリから経路の各構成要素をたどる必要があります。検索権限のないディレクトリは、そのたどりを権限エラーで止めます。ファイル自身のモードは決して参照されないため、完全に読める鍵が読めないように見えます。エラーは開く時点でディレクトリ名を伴わずに現れることが多く、そのため最後のファイルが疑われます。

ディレクトリでは、実行ビットは内容の実行ではなく検索を意味します。鍵はデータのままであり、この修復のどの部分も鍵を実行可能にする必要はありません。

サービスアカウントとして経路をたどる

各構成要素を所有者とモードとともに一覧にし、そのうえで実際のサービスの身元として読み取りを繰り返します。あなたのシェルとデーモンの違いが、しばしば答えのすべてです。検査されるのは解決後の経路なので、シンボリックリンクは実体の目標までたどってください。

namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key

サービスは複数の段階でファイルを開くこともあります。一部の資料は特権的な設定の間に読まれ、別のファイルは特権を落とした後に開かれます。ファイルを読む root シェルは、後から動くワーカーのアクセスを再現しません。マウント名前空間は同じ経路の異なる見え方を提示することがあり、とくにコンテナ内では顕著なので、デーモンのファイルシステムの見え方を自分のものと比較してください。

適合する最も狭い権限を変更する

プロセスにアクセスを与える最小の構成として、必要なディレクトリに検索権限を持つ管理されたグループ、サービスがすでに所有する管理された場所、または別の文書化された仕組みを選びます。ファイルの読み取りに、そのディレクトリへの書き込み権限は必要ありません。特権的な設定に対する広いグループ書き込み権限は、通常のたどり修復ではありません。再帰的な 0777 も解決策ではありません。

どの構成要素を、なぜ変更したかを記録します。理由の記録がない権限変更はレビューが難しく、忘れられやすいものです。

たどりの後にだけモードの先を見る

モードのビットが十分に見えるなら、残る確認は ACL、セキュリティポリシー、サンドボックスの制限です。ACL はモードのビットが欠けていると示すアクセスを与えたり、許可しているように見えるアクセスを拒否したりします。それらの設定は既存の設定の所有者に属し、無効化するのではなく狭く調整すべきです。ルートや作業ディレクトリの違いも、ある文脈では機能し別の文脈では失敗する絶対パスを説明できます。

アクセスを直す間も、ファイルが何であるかを見失わないでください。CA 証明書は設計上公開であり、秘密鍵はそうではありません。クライアントが書き換えるファイルには、読み取り専用の識別鍵とは異なる書き込み権限も必要です。秘密を出力せずにメタデータを確認し、変更後にサービス自体が動くことを確かめてください。サービス文書に短い注記を残せば、次の人が同じたどりをせずに済みます。