Linuxの権限を学ぶと、最初にr、w、xと、755や644の読み方を覚えます。ここまでは計算問題に近く、規則が分かれば読めるようになります。
難しくなるのはその先です。実際のトラブルでは「このファイルを755にすればよいか」ではなく、誰が、どの処理で、何をするためにアクセスするのかを確認しなければなりません。
読み方そのものは当時のメモに書きました（実行ファイルとファイル権限について / 権限管理chmodとchownについて）。この記事は、その先にある「変更してよいか」の判断を足すものです。
まず実行ユーザーを確認する
Webアプリケーションがファイルへ書き込めない場合、操作している自分のユーザーだけを見ても解決しません。Webサーバー、アプリケーション、ジョブなど、実際の処理を動かしているユーザーを確認します。
ps -eo user,pid,ppid,cmd
ls -ld /対象のディレクトリ
namei -l /対象のディレクトリ/対象ファイル対象ファイルだけでなく、そこへ至る親ディレクトリに実行権限があるかも確認します。ファイルの権限は正しく見えるのにアクセスできない場合、途中のディレクトリで止まっていることがあります。
777は原因調査を終わらせてしまう
権限エラーへ遭遇すると、切り分けのため一時的に権限を広げたくなります。しかし、chmod -R 777は問題の所在を曖昧にします。
- 所有者が間違っていたのか
- グループ設計が不足していたのか
- 実行ユーザーの認識が違っていたのか
- アプリケーションが本来不要な場所へ書き込もうとしていたのか
全部を許可すると、どれが原因だったのか分かりません。しかも再帰的な変更は、設定ファイルや秘密鍵など、別の用途のファイルまで巻き込みます。便利な一行ほど、戻すときは便利ではありません。
所有者・グループ・権限を分けて考える
権限トラブルでは、次の順に整理すると見通しがよくなります。
| 確認項目 | 問い |
|---|---|
| 実行主体 | どのユーザー・プロセスがアクセスするか |
| 所有者 | ファイルを管理する主体は誰か |
| グループ | 複数の主体で共有する必要があるか |
| 必要な操作 | 読み取り、書き込み、実行のどれが必要か |
| 対象範囲 | 単一ファイルか、ディレクトリ配下か |
| 継承 | 新しく作られるファイルにも同じ条件が必要か |
複数ユーザーで扱うなら、全員へ権限を開く前にグループを使えないか検討します。共有ディレクトリではsetgidやACLが候補になる場合もありますが、仕組みを増やせば運用ルールも必要です。高度な設定を使うことより、誰が管理するか説明できることを優先します。
変更前後を記録する
変更前にはstatやls -lで状態を残します。
stat /対象のファイル
getfacl /対象のファイルACLを使っていない環境ではgetfaclが入っていないこともあります。その場合でも、少なくとも所有者とモードは記録できます。
変更後は、表示が期待どおりか確認するだけでは不十分です。可能なら実際の実行ユーザーと同じ条件で読み書きを試し、アプリケーションのログも確認します。権限表示が正しくても、SELinuxや読み取り専用マウントなど別の制約が原因になることがあるためです。
クラウドでも考え方は変わらない
IAM、バケットポリシー、コンテナの実行ユーザーなど、クラウドでは権限の登場人物が増えます。それでも基本は同じです。
- 誰が操作するのか
- どのリソースが対象か
- 何の操作が必要か
- どこで拒否されたか
- 必要最小限の変更で解決できるか
Linuxのパーミッションを暗記問題として終わらせず、この型で理解しておくと、IAMの調査でも役立ちます。
今回の要点
- 権限値より先に、実際の実行ユーザーを確認する
- 対象ファイルだけでなく親ディレクトリも見る
- 所有者、グループ、必要な操作を分けて考える
- 再帰的な権限変更は対象範囲と戻し方を確認する
- 表示だけでなく、実際の処理とログで変更結果を検証する
755を読めるようになるのが基礎なら、777を見て少し不安になるのが次の段階です。数字は簡単ですが、誰に何を許すかは普通に設計の話でした。