Skip to content
ブログに戻る
セキュリティ

Linuxファイルパーミッション徹底解説:chmod 755・644・777

Linuxのファイルパーミッションを理解:chmod・8進数(755/644/777)・rwxの仕組み、setuidやumask、安全な既定値まで。無料のchmod計算ツール付き。

11 分で読める

Linuxファイルパーミッション徹底解説:chmod 755・644・777

Linux のファイルパーミッションは、システム上のすべてのファイルとフォルダについて、誰が読み取り・書き込み・実行できるかを決める。各項目には 3 つのユーザークラス(所有者、グループ、その他全員)があり、それぞれのクラスに 3 つのパーミッションビット、すなわち読み取り(r)・書き込み(w)・実行(x)が与えられる。ファイルあたり 9 ビットだ。chmod がこれらを設定し、どこでも見かける略記が 8 進数だ。各クラスの rwx が 0 から 7 までの 1 桁に圧縮される(読み取り 4 + 書き込み 2 + 実行 1)。

実際に打ち込むことになるほぼすべてを、3 つのモードがカバーする:

  • 755rwxr-xr-x)— ディレクトリとスクリプト:所有者は変更でき、その他全員は読み取りと実行ができる。
  • 644rw-r--r--)— 通常のファイル:所有者が書き込み、その他全員は読み取る。
  • 777rwxrwxrwx)— 全員にフルアクセス。ほぼ常に間違いで、何かを直すどころかセキュリティホールを開けてしまう。

無料の chmod 計算ツールで任意の組み合わせを切り替えれば、8 進数・rwx 文字列・正確なコマンドが同時に更新される様子を見られる。この後は、これらの数字がどう動き、それぞれがどこで使われるかを順に見ていく。

Linux のファイルパーミッションを 30 秒で

8 進数シンボリック典型的な用途
400r--------SSH 秘密鍵、読み取り専用
600rw-------プライベートファイル、SSH 鍵、.env
644rw-r--r--Web ページ、設定、ほとんどのファイル
700rwx------プライベートディレクトリ(~/.ssh
755rwxr-xr-xスクリプト、バイナリ、Web ディレクトリ
775rwxrwxr-xグループ共有ディレクトリ
777rwxrwxrwx全員・すべて — 避ける
1777rwxrwxrwt/tmp のような共有一時ディレクトリ

経験則:ファイルは 644、ディレクトリは 755、そこからさらに絞る。 具体的に何かが壊れたときだけモードを緩め、先回りして緩めてはならない。

パーミッションモデル:所有者・グループ・その他

3 つのクラスが 1 つのファイルを共有する。所有者(通常は作成した本人)、単一のグループ、そしてその他、つまり所有者でもグループのメンバーでもないすべてのアカウントだ。各クラスは独立して読み取り・書き込み・実行を得る:

  • 読み取り(r) — ファイルの内容を見る、またはディレクトリのエントリを一覧する。
  • 書き込み(w) — ファイルを変更する、またはディレクトリ内のエントリを追加・削除する。
  • 実行(x) — ファイルをプログラムとして実行する、またはディレクトリに入る(cd する)。

つまずきやすいのはここだ。ディレクトリでは、ビットの意味が異なる。r は名前を一覧でき、w は内部でエントリを作成・削除でき、x は横断(トラバース)して下層のファイルに到達し cd で入れる。ディレクトリに x なしで r だけを持ち、ls は実行できても、入ろうとした瞬間に「Permission denied」になることがある。だからこそディレクトリは 644 ではなく 755 なのだ。

ls -l の行を読む

ls -l を実行すると、どのエントリも 10 文字のブロックで始まる:

$ ls -l
-rw-r--r--  1 jack staff  1400 Jul 17 10:00 index.html
drwxr-xr-x  5 jack staff   160 Jul 17 10:00 assets

左から右に読む。最初の文字はファイルタイプであり、パーミッションではない。- は通常ファイル、d はディレクトリ、l はシンボリックリンク、cb はデバイス、p は名前付きパイプ、s はソケットだ。次の 9 文字は rwx の 3 グループ、すなわち所有者・グループ・その他だ。したがって -rw-r--r-- は、所有者が読み書きし(rw-)、グループとその他は読み取りのみ(r-- r--)の通常ファイルで、これが 644 だ。drwxr-xr-x は 755 のディレクトリだ。

一部のシステムは 9 ビットの後にマーカーを付ける。末尾の . は SELinux コンテキストを示し、+ は基本ビットを超えるルールを ACL が追加していることを意味し、macOS では @ が拡張属性を示す。いずれも 8 進数を変えない。マーカーを無視して 9 文字を読めばよい。

8 進数表記:755 はどのように rwxr-xr-x になるか

8 進数のファイルパーミッションが機能するのは、各パーミッションが 2 の累乗だからだ:

  • 読み取り = 4
  • 書き込み = 2
  • 実行 = 1

クラスが持つビットを合計すると、その桁が得られる。rwx は 4 + 2 + 1 = 7。r-x は 4 + 1 = 5。r-- は 4。したがって rwxr-xr-x は 3 つずつで読むと 7 5 5 になる。rw-r--r-- に同じことをすると 4 + 2、4、4 → 644 だ。これで全部で、8 進数パーミッションは 3 つの独立した和にすぎない。

パーミッションの桁 0〜7 早見表

2 進数パーミッション
0000パーミッションなし
1001実行のみ
2010書き込みのみ
3011書き込み + 実行
4100読み取りのみ
5101読み取り + 実行
6110読み取り + 書き込み
7111読み取り + 書き込み + 実行

8 進数は単に基数 8 であり、各桁は次のクラスへの重複なく 3 ビットを詰め込む。桁の位取り計算に自信がなければ、基数変換ツールが、各パーミッションの桁と同じように基数 8 が 2 進数へどう対応するかを示す。

chmod 755・644・777:実際に打ち込むモード

chmod 755・644・777 の違いを 1 つの表で並べる:

8 進数シンボリック所有者グループその他典型的な用途リスク
644rw-r--r--読み/書き読み読み通常ファイル安全な既定
755rwxr-xr-xすべて読み/実行読み/実行ディレクトリ、スクリプト安全な既定
600rw-------読み/書きプライベートファイル、鍵非常に安全
700rwx------すべてプライベートディレクトリ非常に安全
775rwxrwxr-xすべてすべて読み/実行グループ共有ディレクトリグループが書き込み可
777rwxrwxrwxすべてすべてすべて(避ける)誰でも書き込み可

755 と 644 の違いはビット 1 つ、実行だ。ディレクトリ・スクリプト・バイナリは入る/実行するために x が必要なので 755 に落ち着く。HTML ページ・画像・設定のような通常ファイルには実行可能である理由がないので 644 のままだ。この 2 つを取り違えることが、日常のパーミッションエラーのほとんどの原因だ。

なぜ 777 が危険か。 これはマシン上のすべてのアカウント、侵害されたサービスアカウントや乗っ取られた Web プロセスも含めて、書き込みアクセスを与えてしまう。誰でも書き込めるドキュメントルートは、そこに到達した者が誰でもコードを上書きできるため、サイト改ざんやマルウェア注入への定番の入り口だ。フォーラムの投稿が何かを「動かすために」chmod 777 しろと言うとき、原因はほぼ常に所有権にあり、これは後述する。

1777 という例外。 /tmp は意図的に誰でも書き込み可能だが、安全装置がある。モード 1777 はスティッキービットを追加し、全員がファイルを作成できる一方で、自分が所有しないファイルの削除やリネームを防ぐ。だからこそ共有一時ディレクトリは 1777 では安全だが、素の 777 では決して安全でない。chmod 計算ツールに 777 を入力すると、リスクパネルが即座に警告する一方、1777 は標準的な共有ディレクトリのパターンとして認識される。

数値モードとシンボリックモード

chmod は同じビットを 2 通りで受け取る。

**数値(絶対)**モードは完全な結果を指定する。chmod 755 file は、以前の状態に関係なく 9 ビットすべてを rwxr-xr-x に設定する。これは既知の正しい状態を強制するスクリプトやデプロイで欲しいものだ。

**シンボリック(相対)**モードは変更を記述する。chmod u+x file は 1 ビットだけ反転(所有者に実行を追加)し、それ以外はそのままにする。chmod u=rwx,go=rx file はクラス全体を明示的に設定する。シンボリックモードは、モード全体を書き直すのが大げさになる単発の調整に向く。

# Numeric: overwrite the whole mode
$ chmod 644 report.txt

# Symbolic: change only what you name
$ chmod u+x deploy.sh        # add execute for the owner
$ chmod go-w shared.conf     # remove write from group and others
$ chmod u=rw,go=r notes.md   # set each class explicitly → 644

シンボリックモードの罠が 1 つ。クラスを指定しない chmod +x は umask でフィルタされる。 よくある umask 022 では、chmod +x script.sh は全員に実行を追加するので chmod a+x と一致する。077 のような厳しい umask の下では所有者にしか影響しない。確実な結果が欲しいときはクラスを指定する。所有者だけなら u+x、全員なら a+x だ。

特殊パーミッション:setuid・setgid・スティッキービット

9 個の標準ビットに加えて、4 桁目の先頭 8 進数が 3 つの特殊モード、すなわち setuid・setgid・スティッキービットの三点セットを担う:

  • setuid = 4000 — プログラムは呼び出し元ではなく「ファイル所有者」の権限で実行される。これは root が所有する passwd が、一般ユーザーに root 所有のパスワードデータベースを更新させる仕組みだ。
  • setgid = 2000 — グループに対する同じ考え方だ。ディレクトリでは、新しいファイルがそのディレクトリのグループを継承するようにもなり、共有プロジェクトを一貫してグループ所有に保つ。
  • スティッキービット = 1000 — 共有ディレクトリで削除を制限し、ユーザーが自分のファイルだけを削除できるようにする。1777 の /tmp が典型例だ。
$ chmod 4755 /usr/local/bin/mytool   # setuid
$ chmod 2775 /srv/shared             # setgid on a shared dir
$ chmod 1777 /tmp                     # sticky bit
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 59976 Jul 17 10:00 /usr/bin/passwd

s/S と t/T の大文字小文字ルール

ls -l では、特殊ビットは実行スロットを再利用し、大文字小文字が実行も設定されているかどうかを教える。小文字の s(setuid/setgid)や t(スティッキー)は、特殊ビット「かつ」実行の両方がオンであることを意味し、これが通常の場合だ。大文字の ST は、特殊ビットは設定されているが実行は「オフ」であることを意味し、これは通常は間違いだ。実行不可能なファイルの特殊ビットは何の役にも立たないからだ。

rwsr-xr-x(4755、実行ありの setuid、正しい)と rwSr--r--(4644、実行なしの setuid、疑わしい)を比べてみるとよい。大文字の ST を見かけたら、誰かが誤って実行ビットを落としていないか確認する。

誰も触れない GNU のディレクトリの落とし穴

ここはプラットフォームで挙動が分かれ、多くのチュートリアルが取り違える。Linux(GNU coreutils)では、数値の chmod 755 dir は、そのディレクトリの既存の setuid や setgid ビットをクリアしない。保持する。ディレクトリがすでに 2755(setgid)で、まっさらにするつもりで chmod 755 を実行しても、setgid ビットは残り、ディレクトリは実際にはまだ 2755 のままだ。

実際にクリアするには、明示的に指定する:

$ chmod 00755 dir      # five-digit form zeroes the special digit
$ chmod =755 dir       # = clears every bit not listed
$ chmod u-s,g-s dir    # remove setuid and setgid by name

BSD と macOS は逆のことをする。数値の chmod 755 は既定で特殊ビットをクリアする。だから chmod -R 755 でパーミッションを「リセット」するデプロイスクリプトは、Mac のノートパソコンと Linux サーバーとで挙動が異なる。この保持は GNU coreutils マニュアルに記載されている。迷ったら 5 桁形式か u-s,g-s 形式を使えば、結果はどこでも同じになる。

umask:新規作成ファイルが得るもの

すべてのファイルを手で chmod することはめったにない。ほとんどは作成時にモードが決まり、それを umask が決める。umask は「オフにする」ビットの集合だ。新しいファイルはベース 666 から、新しいディレクトリは 777 から始まり、umask がビットをマスクして取り除く:

effective mode = base & ~umask

ファイルが 777 ではなく 666 から始まるのは、作りたての新規ファイルが既定で実行可能である必要などないからだ。そのビットは chmod +x で意図的に追加する。

umask新規ファイル新規ディレクトリ意味
022644755既定 — その他は読み取り可、書き込み不可
077600700所有者のみプライベート
002664775グループ協働

既定の 022 を手で追ってみる。666 & ~022 = 666 & 755 = 644777 & ~022 = 755。現在の値は umask で確認し、たとえばグループやその他に何も読ませたくないマシンでは umask 077 でセッションの既定を設定する。

chmod と chown:パーミッションと所有権

chmodchown は別の問いに答える。chmod は所有者・グループ・その他が何をできるか、つまりパーミッションビットを変える。chown は所有者とグループが実際に誰なのかを変える。 777 に手を伸ばすことは、しばしばパーミッションの衣装をまとった所有権の問題だ。

典型的なケース。www-data として実行される Web サーバーが、アップロードディレクトリに書き込めない。chmod 777 は全世界に書き込ませることでエラーを消すが、穴を残す。正しい修正は、必要とするプロセスに所有権を割り当てる:

# Wrong: opens the directory to every account on the box
$ sudo chmod -R 777 /var/www/uploads

# Right: give it to the web user, keep a tight mode
$ sudo chown -R www-data:www-data /var/www/uploads
$ sudo find /var/www/uploads -type d -exec chmod 755 {} +
$ sudo find /var/www/uploads -type f -exec chmod 644 {} +

何かが予期せず読めないときの診断順序。まず ls -l を実行して誰が所有しているかを見て、次にモードを解読し、それから修正が chownchmod か、あるいはユーザーをグループに追加することかを判断する。

再帰的パーミッションを正しく行う

一律の chmod -R 755 . は「すべての通常ファイル」を実行可能にしてしまい、よくてノイズ、悪くすると静かなリスクだ。代わりにタイプ別に再帰する:

$ find . -type d -exec chmod 755 {} +   # directories → 755
$ find . -type f -exec chmod 644 {} +   # files → 644

GNU の chmod には、**大文字の X**を使った 1 行のショートカットがある。これはディレクトリと「すでに」実行ビットを持つファイルにだけ実行を追加する:

$ chmod -R u+rwX,go+rX .

chmod 計算ツールは、選んだ任意のモードについてディレクトリのみとファイルのみの find コマンドを生成するので、素の -R に頼る代わりに正しい振り分けをコピーできる。

Linux ファイルパーミッションのベストプラクティス

  • 動く範囲で最小権限を与える。 最も厳しいモードから始め、壊れたものだけを開く。余分な書き込みビットはすべて攻撃対象領域だ。
  • 755 ディレクトリの中に 644 ファイルを既定とする。 この組み合わせは、ほぼすべての Web ルートとリポジトリのチェックアウトに役立つ。通常ファイルが実行を必要とすることはめったにないが、ディレクトリは常に必要とする。
  • サーバーが到達できるものに 777 を決して残さない。 複数のアカウントが書き込む必要があるなら、モードを全世界に開くのではなく、775 か 2775(setgid がグループ所有権を一貫させる)の共有グループを使う。
  • SSH 秘密鍵は 600、最終的には 400 に保つ。 OpenSSH はグループやその他が読める秘密鍵を明確に拒否する。正確な鍵ファイルの要件については OpenSSH マニュアルを参照。公開鍵と authorized_keys は 644 で問題ない。
  • ファイルモードを他の制御と重ねる。 パーミッションは土台だ。フォルダにログインが必要なときは htpasswd ジェネレーターの基本認証と組み合わせ、ファイルモードを Web セキュリティのベストプラクティスガイドで扱う全体像の 1 ピースとして扱う。

FAQ

drwxr-xr-x の先頭にある dl は何を意味するか?

ls -l の行の最初の文字はパーミッションではなくファイルタイプだ。d はディレクトリ、l はシンボリックリンク、- は通常ファイル、cb はデバイス、p は名前付きパイプ、s はソケットを示す。その後の 9 文字だけが、実際の読み取り・書き込み・実行ビットを符号化する。

パーミッションの小文字の s と大文字の S の違いは何か?

小文字の s と大文字の S はどちらも setuid または setgid ビットが設定されていることを意味する。小文字の s は実行も設定されていることを意味し、これが通常の正しく動作する状態だ。大文字の S は特殊ビットはオンだが実行はオフ(4644 のように)であることを意味し、これはほぼ常に設定ミスだ。特殊ビットは実行なしでは無意味だからだ。

umask とは何か、既定のパーミッションをどう決めるか?

umask は、ファイル作成時に「オフ」にされるパーミッションビットの集合だ。新しいファイルはベース 666、ディレクトリは 777 から始まり、その後 effective = base & ~umask がマスクされたビットを取り除く。既定の 022 は 644 のファイルと 755 のディレクトリを生む。umask を実行して自分の値を確認するか、よりプライベートな既定には umask 077 を使う。

644 や 755 の代わりに 400 や 700 を使うべきなのはいつか?

ファイルやディレクトリを完全にプライベートに保つ必要があるときに 400 や 700 を使う。400(r--------)は読み取り専用のプライベートファイルで、二度と編集しない確定した SSH 秘密鍵に最適だ。700(rwx------)は所有者だけが入れるディレクトリで、~/.ssh~/.gnupg のようなものだ。644 や 755 と違い、他の誰にも何も与えない。

ディレクトリを一覧できるのに cd で入れないのはなぜか?

ディレクトリのパーミッションは一覧と横断を分ける。r ビットは名前を一覧させ、x ビットは入ることを許す。r はあるが x がないディレクトリ(644 のディレクトリ)は、ls で名前を表示する一方、cd と内部のファイルへのあらゆるアクセスをブロックする。実行を追加して(755 にして)入れるようにする。

ファイルパーミッションは macOS でも Linux と同じように動くか?

どちらも POSIX に従うため、中核の rwx と 8 進数モデルは両者で共通だが、細部は異なる。BSD と macOS は数値の chmod でディレクトリの setuid/setgid を既定でクリアする一方、Linux はそれを保持する。モードの読み方も異なる。Linux では stat -c '%a' file、macOS では stat -f '%Lp' file、そして macOS は ACL とファイルフラグを追加する。

コマンドラインなしでファイルパーミッションを変更できるか?

ターミナルなしでパーミッションを計算・解読できる。無料の chmod 計算ツールでは、パーミッションのマトリクスにチェックを入れ、8 進数の値を入力し、あるいは ls -l の行を貼り付ければ、正確な chmod コマンドを返してくれる。実際のファイルに適用するには、サーバー上でそのコマンドか、パーミッションフィールドを公開する GUI や FTP クライアントが依然として必要だ。

タグ: linux chmod file-permissions permissions security