drwxr-xr-xの意味と755をわかりやすく解説

drwxr-xr-x の意味

drwxr-xr-x は、所有者が変更でき、その他のユーザーは変更せずに読み取りと通過ができるディレクトリを表します。このモードは 8 進数では 755 です。Linux は ls -l の出力の各行の先頭に、この 10 文字を表示します。文字は常に同じ順序で同じ意味を持つため、1 つ覚えればすべて理解できます。

まず、他のルールより先に確認すべき点があります。自分で行うテスト結果に意味があるかどうかを左右するためです。root ユーザーは権限ビットを無視します。カーネルは root に CAP_DAC_OVERRIDE capability（任意アクセス制御の上書き）を付与するため、モードで禁止されているファイルも root は開けます。このページの例は、ビットの設定にかかわらず root ではすべて成功します。ルールがどのように適用されるかを確認するときは、通常のユーザーでログインしてください。

10 文字を 1 文字ずつ確認する

確認用のディレクトリとファイルを作成します。ここで行う操作が新しいディレクトリの外部に影響することはありません。

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

一般的なデフォルトの umask 022 では、2 つのディレクトリの行は drwxr-xr-x で始まり、ファイルの行は -rw-r--r-- で始まります。

1 文字目は権限ではなく、ファイル種別です。d はディレクトリです。- は通常のファイルです。l はシンボリックリンクです。c と b はキャラクタデバイスとブロックデバイスのノードです。s はソケット、p は名前付きパイプです。この文字は 8 進数の値には含まれません。そのため、drwxr-xr-x は d で始まる値ではなく、755 になります。

その後ろの 9 文字は 3 文字ずつの 3 グループに分かれており、順序は変わりません。

• 2 文字目から 4 文字目までは 所有者 の 3 文字です。ファイルを所有するユーザーに適用されるビットを示します。
• 5 文字目から 7 文字目までは グループ の 3 文字です。ファイルのグループに適用されるビットを示します。
• 8 文字目から 10 文字目までは その他 の 3 文字です。それ以外のすべてのユーザーに適用されるビットを示します。

各 3 文字の位置は常に r、w、x の順です。ハイフンはそのビットが無効であることを示します。各文字の位置が入れ替わることはありません。r-x は読み取りのみを示します。-w- は読み取りなしの書き込みを示します。この設定は可能ですが、一般的ではありません。

したがって、drwxr-xr-x は次のように分解できます。d がディレクトリ、rwx が所有者、r-x がグループ、r-x がその他を示します。

システムによっては 11 文字目が表示されます。末尾のドットである drwxr-xr-x. は、そのファイルに SELinux（security enhanced Linux）のコンテキストが付いていることを示します。Fedora や Rocky などの SELinux ディストリビューションでは、デフォルトで表示されます。末尾のプラス記号である drwxr-xr-x+ は、そのファイルに POSIX ACL（access control list）が付いていることを示します。これは、9 個のビットに加えて適用される追加のルールです。getfacl <path> で追加のルールを確認できます。

ディレクトリでは r、w、x が異なる役割を持ちます

これは、初心者が最初に間違えやすいルールです。ファイルとディレクトリでは同じ文字を使いますが、付与される権限は異なります。

• ファイルの r は内容を読み取ります。ディレクトリの r は内部の名前を一覧表示します。通常の ls に必要なのはこの権限です。
• ファイルの w は内容を変更します。ディレクトリの w は、その中のエントリを追加・削除します。ファイルの削除はディレクトリへの変更なので、決め手になるのはディレクトリの write 権限です。ファイル自体のモードは関係ありません。
• ファイルの x は、ファイルをプログラムとして実行します。ディレクトリの x は、ディレクトリを通過します。つまり、パス検索中にカーネルが内部の名前を解決できるようにします。

通過の仕組みは、分かりにくい部分です。ディレクトリの x は何も実行しません。/srv/site/index.html を開くには、まず x が / に必要です。次に x が /srv に必要で、続いて x が /srv/site に必要です。最後に、ファイルに r が必要です。その経路上のいずれかのディレクトリで、ユーザーに対する x が不足していると、そこで検索が停止します。この場合、末尾のファイルが誰でも読み取れる状態でも、呼び出し元にはパス全体について Permission denied が返されます。namei -l /srv/site/index.html は経路上の各段階を、モードと所有者とともに表示します。どの箇所で停止しているかを確認できます。

r があり、x がないディレクトリは、認識しておくべき特殊な中間状態です。通常のユーザーは名前を一覧表示できます。これは r が付与する権限です。ただし、各エントリの stat 情報は取得できません。そのため ls -l はサイズ列とモード列を疑問符で埋め、各エントリについて ls: cannot access ...: Permission denied を表示します。

文字を 755 に変換する

各 3 文字の組は、3 ビットの数値です。r は 4、w は 2、x は 1 を表します。オンになっているビットを合計します。

• rwx は 4 + 2 + 1 = 7 です
• rw- は 4 + 2 = 6 です
• r-x は 4 + 1 = 5 です
• r-- は 4 です
• --- は 0 です

したがって、drwxr-xr-x は所有者が 7、グループが 5、その他が 5 で、755 になります。-rw-r--r-- は 6、4、4 で、644 です。drwxrwxr-x は 7、7、5 で、グループに書き込み権限を追加した 755 に相当する 775 です。stat は両方の形式を同時に表示するため、文字を手作業で数える必要はありません。

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A は文字形式、%a は 8 進数形式、%U と %G は所有ユーザーと所有グループを示します。

実際のサーバーでよく使うパーミッション文字列

実際のサーバーで使用するモードを、8 進数の値と用途とともに示します。

• -rw-r--r-- は 644 です。サービスが読み取るだけの通常ファイルで、設定ファイルや HTML ページなどが該当します。
• -rw------- は 600 です。SSH 秘密鍵や、アプリケーションの .env ファイルなどの Secret に使用します。
• -rw-rw-r-- は 664 です。グループで共有するディレクトリ内のファイルで、チームメンバーによる書き込みが必要な場合に使用します。
• -rwxr-xr-x は 755 です。/usr/local/bin/backup.sh や、ほとんどの /usr/bin などのスクリプトやバイナリに使用します。
• -rwx------ は 700 です。所有者だけが実行できる非公開スクリプトに使用します。
• drwxr-xr-x は 755 です。ほぼすべてのシステムディレクトリや、Web サイトのドキュメントルートに使用します。
• drwx------ は 700 です。~/.ssh や、アクセスを厳しく制限した環境のホームディレクトリに使用します。
• drwxrwxr-x は 775 です。所有者のグループが書き込めるディレクトリに使用します。
• drwxrwsr-x は 2775 です。drwxrwxr-x と同じですが、setgid ビットも設定されるため、内部に新しく作成したファイルはディレクトリのグループを継承します。
• drwxrwxrwt は 1777 です。/tmp。末尾の t は sticky bit であり、ユーザーは自分のファイルだけを削除できます。
• -rwsr-xr-x は 4755 です。所有者の権限で実行される setuid バイナリに使用し、/usr/bin/passwd や /usr/bin/sudo などが該当します。
• -rw-rw-rw- は 666、drwxrwxrwx は 777 です。全ユーザーが書き込める状態であり、サーバーではほぼ常に設定ミスです。
• lrwxrwxrwx は、すべてのシンボリックリンクに表示される値です。Linux はリンクのモードビットを無視し、リンク先を確認するため、この文字列自体にはまったく意味がありません。

自分に適用されるトライアド

初心者が間違えやすい2つ目のルールです。カーネルはトライアドを必ず1つだけ選び、そこで判定を終了します。

ユーザー ID がファイルの所有者と一致する場合は、所有者トライアドが適用されます。グループとその他のビットは確認されません。一致しない場合、ファイルのグループが自分の所属グループのいずれかであれば、グループトライアドが適用されます。それ以外の場合は、その他トライアドが適用されます。

ここから2つの点が分かります。所有者トライアドは、それが最も制限の厳しいものであっても適用されます。モード 0466 のファイルは -r--rw-rw- と表示され、所有者には読み取りだけを許可し、他の全員には書き込みを許可します。最初に所有者として一致するため、その後のビットは確認されないからです。これは正しい動作ですが、初めて見ると混乱しやすい例です。

グループトライアドを選ぶ基準は、所属しているグループの一覧ではなく、ファイルのグループです。ls -l は各行に2つの名前を表示します。先に所有者、次にグループです。そのファイルに対して意味を持つのは、後者のグループだけです。20個のグループに所属していても、ファイルのグループがそのいずれかである場合にだけ効果があります。

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id は、自分のユーザーと所属するすべてのグループを表示します。stat は、ファイルの所有者とグループを表示します。両者を比較すれば、カーネルが自分に使用するトライアドが分かります。

このため、共有ディレクトリには通常、グループと setgid ビットを設定します。sudo chmod 2775 /srv/shared は drwxrwsr-x と表示されます。ディレクトリ内で作成されたファイルは、作成者個人のグループではなく、そのディレクトリのグループを継承するため、次のユーザーも引き続き書き込めます。各サービスに専用アカウントを割り当てることも、この仕組みの重要な要素です。詳しくは VPS 上でサービスごとに Linux ユーザーを1つ割り当てる で説明しています。

umask はすべての新規ファイルのモードを決定します

新規ファイルのモードは、ユーザーが直接指定した値から決まるわけではありません。作成したプログラムが指定したモードから、umask がクリアするビットを除いた値になります。umask は削除するビットのマスクです。そのため、umask が大きいほど、ファイルはより限定的なアクセス権になります。

ほとんどのディストリビューションでは 022 が設定されています。通常ファイルを作成するプログラムは 0666 を要求します。ディレクトリを作成するプログラムは 0777 を要求します。umask は両方の要求から 022 をクリアするため、ファイルは 644、ディレクトリは 755 になります。新規作成した VPS でよく確認する組み合わせは、この値です。

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S は同じ値を文字形式で表示するため、0022 より読みやすくなります。より厳しいデフォルトにするには、umask 027 に ~/.profile を設定します。ファイルは 640、ディレクトリは 750 になります。これにより、グループには作業ファイルの読み取りを許可し、それ以外のユーザーには許可しません。

重要な制限が 2 つあります。umask で設定できるのはビットのクリアだけで、追加はできません。そのため、どのように設定しても、新規作成したファイルが実行可能になることはありません。また、systemd サービスはシェルのプロファイルを読み込まないため、値は unit ファイルで設定してください。

[Service]
UMask=0027

Web ファイルを 644、Web ディレクトリを 755 にする理由

Web サーバーは専用アカウントで実行されます。Debian と Ubuntu では www-data、Rocky と Alma では nginx です。このプロセスには、配信するファイルへの読み取り権限と、その上位にあるディレクトリへの通過権限が必要です。ファイルを書き込む必要はありません。静的サイトでは、書き込みを許可すべきではありません。

ファイルの 644 は、所有者に書き込み権限を与え、全員に読み取り権限を与えます。そのため、deploy ユーザーは公開でき、Web ユーザーは配信できます。ディレクトリの 755 は、所有者に書き込み権限を与え、全員に通過権限を与えます。そのため、Web ユーザーはパスをたどれますが、何かを追加または削除することはできません。アプリケーションにバグがあっても、配信中のページを書き換えることはできません。

ここで重要になるのが通過権限です。サイトが /home/deploy/site にあり、/home/deploy が 750 の場合、Web ユーザーはホームディレクトリに入れません。その結果、リクエストは HTTP 403 で終了し、/var/log/nginx/error.log に次のような行が記録されます。

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

この 13 は EACCES で、カーネルが権限不足として拒否したことを示します。ネットワークに問題があるわけではありません。ポートは待ち受け中で、リクエストも到着しています。そのため、Linux で 待ち受けポートがどのように機能するかを学んでいる段階では、原因が分かりにくくなります。namei -l /home/deploy/site/index.html を実行し、チェーンを上から確認して、x がない最初のディレクトリを探します。

アップロード先のように、アプリケーションが書き込むディレクトリは例外です。その場合は、より広いモードではなく所有権で許可します。sudo chown -R www-data:www-data /srv/site/uploads を実行し、モードは 755 のままにします。書き込みアクセスは、必要な 1 つのディレクトリだけに限定してください。

chmod でディレクトリツリー全体の権限を一律に変更しない

chmod には 2 つの形式があります。8 進数形式では 9 つのビットを一度に設定します: chmod 644 notes.txt。シンボリック形式では指定した部分だけを変更し、それ以外はそのままにします: chmod u+x deploy.sh は所有者に実行権限を追加し、chmod go-w notes.txt は group と other から書き込み権限を削除します。

再帰処理では、ディレクトリツリーを壊さないように注意が必要です。chmod -R 755 . を使うと、すべての画像ファイルと設定ファイルに実行権限が設定されます。chmod にはスクリプトと JPEG を区別できないためです。代わりに大文字の X を使用してください。

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

大文字の X は、ディレクトリと、どこかのクラスに実行ビットがすでに設定されているファイルに実行権限を適用します。ディレクトリは 755、通常のファイルは 644 になり、すでに実行可能だったスクリプトはその状態を維持します。信頼できるモードのファイルが 1 つある場合は、chmod --reference=good.sh other.sh でそのモードを他のファイルにコピーできます。

エラー発生時に表示されるメッセージ

bash: ./deploy.sh: Permission deniedは、スクリプトに対象の triad に適用できる x ビットがないか、パス上のディレクトリに x がないことを示します。最初のケースは chmod u+x deploy.sh で修正できます。

bash: ./deploy.sh: cannot execute: required file not foundは、分かりにくい名前の別のエラーです。x ビットには問題がなく、1 行目で指定された interpreter が見つかりません。通常の原因は Windows の改行コードです。そのため、kernel は /bin/bash\r という名前の interpreter を探します。sed -i 's/\r$//' deploy.sh で修正できます。

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open.は SSH client が出力するエラーです。SSH client は、他のアカウントから読み取れる private key の使用を拒否します。key の権限は 600、~/.ssh の権限は 700 にします。key の取り扱い全般については、SSH key とファイル権限の管理を参照してください。

Authentication refused: bad ownership or modes for directory /home/deploy/.sshは、home directory またはその .ssh が group から書き込み可能な場合に、server の journal に表示されます。sshd の StrictModes 設定が key を拒否するため、client 側では説明のない予期しない password prompt に見えます。

sudo: /etc/sudoers is world writableに続いて sudo: no valid sudoers sources found, quittingが表示される場合、sudo は自身の config の mode を確認し、実行を拒否しています。このファイルの権限は 0440 にする必要があります。これは広範な再帰的 chmod の後によく発生します。上記の sshd メッセージも同時に表示されることがあり、その場合、復旧手段は provider の console だけになります。

777 が解決策にならない理由

777 は、マシン上のすべてのアカウントと、それらのアカウントで実行されているすべてのプロセスに書き込み権限を与えます。サーバーでは、サービスを専用のユーザーで実行します。そのため、VPS における「全員」は、ラップトップの場合よりはるかに広い範囲を指します。サービスが侵害されると、777 で許可されるあらゆる場所に書き込めます。

Web ルートでは、被害が直接発生します。サーバーが配信するディレクトリに全ユーザーの書き込み権限があると、ファイルアップロードの脆弱性によってスクリプトを配置し、そのスクリプトをリクエストできるようになります。

777 は、所有者に関する問題への回答としては、ほぼ常に誤りです。症状は「アプリがこのディレクトリに書き込めない」です。原因は、ディレクトリの所有者が誤っていることです。sudo chown -R appuser:appuser /srv/app/storage をモード 755 で設定すれば解決し、他のすべてのアカウントを締め出せます。何かをデプロイする前にこれらのアカウントを作成する手順については、新しい VPS で最初の 10 分に行う作業を参照してください。

全ユーザーによる書き込みが正当なのは、よく知られた 1 か所、/tmp です。その表記は drwxrwxrwt です。末尾の t は sticky bit です。この設定では、ディレクトリに全員が書き込めますが、各ユーザーが削除できるのは自分が所有するファイルだけです。このビットがなければ、どのアカウントでも他のアカウントの一時ファイルを削除できます。

変更する前にモードを確認する

これらのコマンドは状態を読み取るだけなので、どこでも安全に実行できます。

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002は、world write ビットが設定されたパス配下のすべてを一覧表示します。chmod 777で誰かが修復作業を行った後に、システムを監査する最も迅速な方法です。

特定のサービスアカウントがディレクトリに入れるか確認するには、そのアカウントとして確認します。sudo -u www-data test -x /srv/site && echo yes || echo noは、そのユーザーにディレクトリの traverse 権限がある場合は yes、ない場合は noを出力します。root として確認しても意味はありません。root はこのチェックを回避するため、結果は常に yesになります。

FAQ

Linux で drwxr-xr-x は何を意味しますか？

先頭の d で示されるディレクトリで、モードは 755 です。所有者の3文字は rwx なので、所有者はすべての権限を持ちます。グループの3文字は r-x、その他のユーザーの3文字は r-x です。そのため、所有者以外はディレクトリ内の名前を一覧表示して通過できますが、追加や削除は誰もできません。任意のパスについては stat -c '%A %a %U %G %n' <path> で確認できます。これは文字形式と8進数形式を横に並べて表示します。

Web ファイルが 644 で、Web ディレクトリが 755 なのはなぜですか？

Web サーバーは、Ubuntu では www-data という別のアカウントで実行されます。配信するファイルには読み取り権限が必要で、そのファイルまでのすべての親ディレクトリには通過権限が必要です。一方、どちらにも書き込み権限は必要ありません。644 では所有者に書き込み権限があり、その他のユーザーには読み取り権限があります。755 では所有者に書き込み権限があり、その他のユーザーには通過権限があります。アプリケーションが実際に書き込む必要のあるディレクトリは、全員に対してモードを広げるのではなく、chown でそのアプリケーションのユーザーに所有させます。

x ビットはディレクトリを実行できることを意味しますか？

いいえ。ディレクトリの x は通過を意味します。これは、カーネルがパスをたどる際に、内部の名前を1つ解決する権限です。cd にも必要であり、その下にあるファイルを開く場合にも必要です。パス上の各ディレクトリには x が必要です。そのため、あるディレクトリの x が自分に対して設定されていなければ、モード 644 のファイルにも到達できません。namei -l /path/to/file はパスの各ディレクトリのモードを表示し、名前解決がどこで止まるかを示します。

chmod 777 が正しい対処になることはありますか？

サーバーでは、ほとんどありません。マシン上のすべてのアカウントに書き込み権限を与えるため、サービスの実行アカウントも含めて、侵害された1つのサービスがファイルを書き換えられるようになります。アプリケーションがディレクトリに書き込めない場合、本当の問題は通常、所有権です。sudo chown -R appuser:appuser /srv/app/storage とモード 755 を設定すれば、アプリケーションに必要な権限を与えながら、その他のユーザーを排除できます。よく知られた例外は /tmp を 1777 にする場合です。ただし、これは sticky bit によってユーザーが互いのファイルを削除できないために機能します。

ls が権限の後ろにドットまたはプラスを表示するのはなぜですか？

11文字目は、9個の権限ビット以外に設定された規則を示します。drwxr-xr-x. のようなドットは、SELinux セキュリティコンテキストが付加されていることを意味します。Fedora や Rocky では通常の状態です。drwxr-xr-x+ のようなプラスは、POSIX ACL（アクセス制御リスト）が設定されていることを意味します。3つの権限セットには表示されない権限を、特定のユーザーまたはグループが持っています。追加のエントリは getfacl <path> で一覧表示できます。