パーミッションは、ファイルやディレクトリを「誰が」「何をできるか」を決める設定です。Linux や macOS では、所有者（オーナー）・グループ・その他の3者それぞれに、読み取り（r）・書き込み（w）・実行（x）を許可するかどうかを持っています。chmod はこれを変えるコマンドで、chmod 755 や chmod 644 のような数字でも、chmod u+x のような記号でも指定できます。

この記事では、ls -l の表示の読み方から始めて、レンタルサーバーで指定される数値、ディレクトリでの r・w・x の意味、umask、特殊ビットを順に確認します。コマンドの結果はすべて 2026-10-02 に次の2つの環境で実際に実行したものです。

  • Docker 上の Debian 13（GNU coreutils 9.7、GNU findutils 4.10.0）。ディレクトリの確認は一般ユーザーで実行しました。root はほとんどのパーミッション検査を通過してしまうためです。
  • macOS 27.0.1（BSD 系の chmod・stat・find）

記号表記・数値・コマンドの例は chmod 計算機 の出力で、サイトのテストが計算機のコードから同じ値を再計算しています。

ls -l の10文字を読む

ls -l の先頭10文字は、1文字目がファイルの種類、残り9文字がパーミッションです。Debian 13 で確認した2つを例にします。

$ stat -c '%a %A %n' /usr/bin/passwd /tmp
4755 -rwsr-xr-x /usr/bin/passwd
1777 drwxrwxrwt /tmp

1文字目の - は通常ファイル、d はディレクトリ、l はシンボリックリンクです。続く9文字を3文字ずつ区切ると、所有者・グループ・その他の順になります。rwxr-xr-x なら、所有者は読み書き実行、グループとその他は読み取りと実行ができます。

実行権の位置に s や t が出ているのが特殊ビットです。s は SUID（所有者の位置）または SGID（グループの位置）、t はスティッキービットです。下にある実行権が付いていないときは大文字の S・T になります。Debian で chmod 4644 としたファイルは -rwSr--r--、chmod 1770 としたディレクトリは drwxrwx--T と表示されました。

ls -l の10文字目に +（ACL がある）、@（macOS の拡張属性）、.（SELinux のコンテキスト）が付くこともあります。計算機の「シンボル」欄はこれらの付いた文字列をそのまま貼り付けても読み取れます。

数字表記：r=4、w=2、x=1 の足し算

数字表記（8進数表記）では、r を 4、w を 2、x を 1 として3者それぞれの合計を1桁で書きます。

数字2進数記号許可されること
7111rwx読み取り・書き込み・実行
6110rw-読み取り・書き込み
5101r-x読み取り・実行
4100r--読み取り
0000---なし

755 は所有者 7、グループ 5、その他 5 で rwxr-xr-x、644 は rw-r--r-- です。4桁で書いたときの先頭の桁は特殊ビットで、SUID が 4、SGID が 2、スティッキービットが 1 です。2775 は 775 に SGID を加えた値です。

記号表記は「誰に」（u 所有者、g グループ、o その他、a 全員）、「どうする」（+ 追加、- 削除、= 指定）、「何を」（r w x）の組み合わせです。

chmod u+x deploy.sh        # 所有者に実行権を追加
chmod go-w shared.cfg      # グループとその他から書き込み権を削除
chmod u=rw,go=r memo.txt   # rw-r--r-- にする
chmod a+x tool             # 全員に実行権を追加

chmod +x のように「誰に」を省くと、POSIX の chmod の仕様により umask で立っているビットは変わりません。Debian と macOS のどちらでも、umask が 077 のとき 644 のファイルに chmod +x を実行すると 744（所有者だけに x）、chmod a+x なら 755 になりました。全員に付けたいときは a+x と書くほうが確実です。

レンタルサーバーの推奨値を読む

共用のレンタルサーバーでは、マニュアルに数値で推奨値が書かれていることが多くあります。ロリポップ！のマニュアル「パーミッションについて」（2026-10-02 確認）の推奨値を記号表記に直すと次のとおりです。

対象推奨値記号表記
HTML・画像ファイル604rw----r--
CGI の実行ファイル700rwx------
CGI のデータファイル600rw-------
.htaccess604rw----r--
ディレクトリ705rwx---r-x

604 や 705 はグループに何も与えず、その他にだけ読み取りを残す値です。同じマニュアルには「CGI 実行ファイルは777」「データファイルは666」と書かれた設置手順について、ロリポップ！ではセキュリティ上その設定では動作しない場合があるので表のとおりにするよう書かれています。

WordPress の公式ドキュメント「Changing File Permissions」も、PHP がファイルの所有者として動く suexec 方式の共用サーバーについて、ディレクトリは 755 か 750、ファイルは 644 か 640、wp-config.php は他のユーザーに読まれないよう 440 か 400 とし、アップロード用でも 777 にしないよう書いています。PHP が所有者の権限で動くので、755 のディレクトリにも書き込めるためです。FTP ソフトでパーミッションを変える画面も同じ3桁の数字を受け付けるので、手元で計算機に数字を入れて記号表記を確かめてから設定すると間違いが減ります。

ディレクトリの r・w・x は意味が違う

ディレクトリは「名前の一覧」です。r は一覧を読む権利、x は中を通ってファイルにたどり着く権利（検索権）、w は名前の追加・削除・変更の権利で、3つは独立しています。Debian で alice が所有する /srv/box（中に 644 の note.txt）を、別ユーザーの bob から操作しました。

/srv/box のモードbob の ls /srv/boxcat /srv/box/note.txtcd /srv/box
744（その他 r--）note.txt と表示Permission deniedできない
711（その他 --x）cannot open directory中身を表示できる

r だけで x がないと、ls -l は名前以外の列がすべて ? になりました。ファイルの情報を取り出せないためです。逆に x だけあれば、名前を知っているファイルは開けます。macOS でも、所有者が自分のディレクトリから x や r を外すと同じ傾向になりました。

w はファイル自体ではなくディレクトリに対する権利です。777 のディレクトリでは、alice が 444（読み取り専用）にしたファイルを bob が rm -f で削除でき、終了ステータスは 0 でした。削除はディレクトリの一覧を書き換える操作だからです。

umask：Debian や Ubuntu で新規ファイルが 664 になる理由

プログラムは通常、ファイルを 666、ディレクトリを 777 で作ろうとし、カーネルが umask で立っているビットを取り除きます。umask が 022 なら 644 と 755、002 なら 664 と 775、077 なら 600 と 700 です。

macOS の umask は 0022 でした。一方、Debian 13 と Ubuntu 24.04 のコンテナで useradd -m で作ったユーザーに su で切り替えると umask は 0002 で、touch したファイルは 664、mkdir したディレクトリは 775 になりました。どちらも /etc/login.defs が USERGROUPS_ENAB yes で、ユーザー名と同じ名前のグループを主グループに持つユーザーはグループ側のビットが緩められます。新しいホームディレクトリのモードを決める HOME_MODE は Debian 13 が 0700、Ubuntu 24.04 が 0750 でした。手順書どおりに作ったはずのファイルが 664 になっていたら、まず umask を確認してください。

一括で変更するときは find と大文字の X

chmod -R 755 site/ はディレクトリだけでなくファイルにも 755 を付けるので、HTML や画像まで実行可能になります。ディレクトリとファイルで値を分けるには find を2回使います。

find site -type d -exec chmod 755 {} +
find site -type f -exec chmod 644 {} +

全体が 777 だったツリーにこれを実行すると、Debian では site と site/css が 755、index.html と css/site.css が 644 になりました。

もう一つの方法が記号表記の大文字 X です。ディレクトリと、すでに誰かに実行権があるファイルにだけ x を付けます。

chmod -R u=rwX,go=rX site

700 のディレクトリ、600 のファイル、700 のスクリプトから始めると、GNU と macOS のどちらでも順に 755・644・755 になりました。誤って付いた実行権を外したいときは X では外れないので、find の方法を使います。

特殊ビット：SUID・SGID・スティッキービット

SUID（4000） を付けたプログラムは、実行した人ではなくファイルの所有者の権限で動きます。root が所有する /usr/bin/id のコピーを 4755 にして bob が id -u を実行すると 0 が表示されました。ところが同じモードのシェルスクリプトでは bob 自身の ID 1001 が表示されました。execve(2) に、Linux はスクリプトの SUID・SGID ビットを無視すると書かれています。

SGID（2000）をディレクトリに付けると、その中に作られたファイルは作成者の主グループではなくディレクトリのグループになります。グループ devs の 2775 ディレクトリで alice が作ったファイルは devs、新しいサブディレクトリは SGID を引き継いで 2775 でした。SGID のない 775 のディレクトリでは alice 自身のグループになりました。チームの共有ディレクトリに使う理由はこれです。macOS は BSD の流儀で、SGID がなくても新しいファイルはディレクトリのグループになります。グループが everyone のディレクトリで作ったファイルは everyone でした。

スティッキービット（1000） を付けたディレクトリでは、他人のファイルを削除・名前変更できなくなります。unlink(2) は、ディレクトリにスティッキービットがあり、実行者がファイルの所有者でもディレクトリの所有者でもなく特権もない場合に EPERM を返します。1777 のディレクトリで、bob は alice の 666 のファイルを削除も改名もできませんでした（Operation not permitted）。ただしファイル自体のモードは 666 なので、追記はできました。/tmp が 1777 なのはこのためです。

macOS と Linux で結果が変わるコマンド

GNU の chmod は、明示的に外さない限りディレクトリの SUID・SGID を残します。coreutils のマニュアル「Directories and the Set-User-ID and Set-Group-ID Bits」に GNU の拡張として書かれた動作です。2775 のディレクトリから始めた結果は次のとおりです。

コマンドGNU coreutils 9.7macOS 27.0.1
chmod 755 d2755（SGID が残る）755
chmod 0755 d2755755
chmod 00755 d755755
chmod =755 d755エラー（Invalid file mode）
chmod u=rwx,g=rx,o=rx d2755755
chmod g-s d775775

Mac で書いたデプロイスクリプトを Linux サーバーで動かすと、chmod 755 で外したつもりの SGID が残ります。外したいときは chmod g-s と書くのがどちらでも通じる方法です。ほかにも、「いずれかのビットが立っている」を GNU の find は -perm /022 と書きますが、macOS の find はこれを illegal mode string として拒否し -perm +022 を使います。また macOS の chmod はディレクトリへの o+t をエラーなしで無視し、+t なら両方で効きました。

SSH 秘密鍵の「UNPROTECTED PRIVATE KEY FILE!」

秘密鍵のパーミッションが緩いと、OpenSSH は鍵を読み込みません。authfile.c の判定は (st.st_mode & 077) != 0、つまりグループかその他に1ビットでも権限があれば拒否です。macOS の OpenSSH 10.3p1 で ssh-keygen -y -f を試すと、600・400・700 は読み込め、640・604・644・660 では次のように表示されて拒否されました。

WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'k' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

エディタに貼り付けて保存し直した鍵や cat > id_ed25519 で作った鍵は、umask が 022 なら 644 になり、このエラーになります。chmod 600 ~/.ssh/id_ed25519 で直ります。サーバー側の sshd には既定で有効な StrictModes があり、ログイン前にホームディレクトリや ~/.ssh のモードと所有者を確認します。chmod -R 775 ~ のような操作の後に公開鍵ログインが急にできなくなったら、ここを疑います。

find -perm でモードからファイルを探す

find -perm には3つの書き方があります。Debian で a（755）、b（775）、c（644）、d（4755）の4ファイルに試した結果です。

条件意味見つかったファイル
-perm 0755モードがちょうど 755a
-perm -0755これらのビットがすべて立っているa、b、d
-perm /022（GNU）、-perm +022（macOS）どれか1つでも立っているb
-perm -4000SUID が立っているd

ドキュメントルートでグループやその他が書き込めるファイルを探すなら、Linux では find /var/www -perm /022 です。

パーミッション計算機で確認する

chmod 計算機 は、チェックボックスか数字（3桁または4桁）から、記号表記、数字の chmod コマンド、記号表記の chmod コマンド、find -perm のコマンドを表示します。「シンボル」欄に ls -l からコピーした drwxrwsr-x を貼り付けると、次のようになります。

数値              2775
シンボル          rwxrwsr-x
コマンド          chmod 2775 filename
シンボルコマンド  chmod u=rwx,g=rwxs,o=rx filename
find -perm        find . -type f -perm 2775

コピーするときの注意が3つあります。find のコマンドは常に -type f の完全一致なので、ディレクトリのモードなら -type d に、SGID の付いたものをすべて探すなら -perm -2000 に書き換えてください。記号表記のコマンドは絶対指定なので、GNU では chmod 755 と同じくディレクトリの SGID を残します。スティッキービットが o+t ではなく別の +t になっているのは、macOS が o+t を無視するためです。計算はページ内で行われ、入力はサーバーに送られません。

パーミッションはアクセス制御の一部にすぎません。ACL（ls -l の +）、SELinux、noexec や nosuid を付けたマウント、そして途中にあるすべての親ディレクトリの x が、モードの上では許可されている操作を止めることがあります。