chmod 權限教學：看懂 755、644、600 與 setuid、setgid、sticky bit

一般權限由三組、每組三個位元構成：u 是檔案擁有者、g 是檔案所屬群組、o 是其他使用者。「擁有者」是擁有該檔案的帳號，不一定是目前操作的你。

在一般模式位元的判定中，擁有者適用 u；不是擁有者、但群組身分符合檔案所屬群組者適用 g；其餘適用 o。不能把不同類別的權限相加，補足原本不足的權限。存取控制清單（ACL）、特權及安全政策等還可能另外影響結果。解析路徑時，沿途的目錄也需要搜尋權限。

• r = 4，讀取：檔案可讀取內容；目錄可列出項目名稱。取得目錄項目的詳細資訊通常還需要 x。
• w = 2，寫入：檔案可修改內容；目錄則涉及新增與刪除項目，通常還需要搜尋權限。這與目錄內檔案本身的權限不同。
• x = 1，執行／搜尋：檔案可執行；目錄可搜尋與通過，包括用 cd 進入。要列出目錄內的名稱，仍需 r。

將需要的值相加，就會得到 0～7 的一位數。依序排列擁有者、群組、其他使用者的三個數字，就形成 755 這類表示法。

以下是常見用途，並非所有環境都必須使用的固定值。應先確認哪些帳號實際需要存取。

建立檔案時，程式會要求一個模式，再由行程的 umask 加以限制。假設程式對一般檔案要求 0666、對目錄要求 0777，umask 為 0022 時，通常會得到 0644 與 0755。0666／0777 是建立時的要求範例，不是 chmod 的計算基準；ACL 等機制也可能影響最終模式。

# umask 為 022，以下數值均為八進位
檔案：666 & ~022 = 644 (rw-r--r--)
目錄：777 & ~022 = 755 (rwxr-xr-x)

# umask 為 002
檔案：666 & ~002 = 664 (rw-rw-r--)
目錄：777 & ~002 = 775 (rwxrwxr-x)

這是位元遮罩運算，不是十進位減法。

POSIX 也定義了 chmod 的符號模式。將對象 u/g/o/a、運算子 +/-/= 與權限字元組合，多個操作以逗號分隔。GNU chmod 可使用 r/w/x/X/s/t，也能以 u/g/o 複製另一類別的權限。

chmod u=rwx,g=rx,o=rx,u-s,g-s,o-t file  # 要求 0755，並明確清除特殊位元
chmod u+x script.sh                    # 只增加擁有者的執行權限
chmod -R go-w /path                    # 遞迴移除群組與其他使用者的寫入權限
chmod a+r file                         # 為所有類別增加讀取權限

請把範例路徑換成實際目標。使用遞迴操作前，先確認影響範圍，以及該 chmod 實作如何處理符號連結。

• 對象：u 為擁有者、g 為群組、o 為其他使用者，a 代表三者。
• 運算子：+ 增加位元、- 移除位元、= 替換指定類別的權限；但須注意 GNU 對目錄 set-ID 位元的保留規則。
• 權限：r/w/x 是一般權限；s 對應 setuid／setgid，t 對應 sticky bit。X 是有條件的執行／搜尋位元，例如 +X 只在目標為目錄，或某個類別原本已有 x 時，才增加 x。

對象可以省略，但此時 umask 遮罩所涵蓋的位元不會變更。因此，不能把 chmod +x 與 chmod a+x 一概視為相同操作。

符號模式適合表達局部變更，例如 chmod go-w file 只移除群組與其他使用者的寫入權限。數值模式能簡潔指定一般權限，但 GNU chmod 對目錄可能保留既有的 setuid／setgid，除非明確要求清除。套用後要連同特殊位元一起檢查。

看到 4755 這類四位數時，最前面一位是 setuid = 4、setgid = 2、sticky = 1 的總和，與後三位的讀取／寫入／執行不同。

• setuid（4000）：對執行檔而言，執行時可將行程的有效使用者 ID 設為檔案擁有者的 ID。
• setgid（2000）：對執行檔而言，可將有效群組 ID 設為檔案所屬群組；對目錄而言，在其中新建的項目會繼承該目錄的群組。
• sticky bit（1000）：用於目錄時，會進一步限制刪除與重新命名，只有項目擁有者、目錄擁有者或具足夠特權的行程可以進行。

符號表示中的 x 位置可能顯示 s/S 或 t/T。小寫代表對應的 x 也有設定；大寫則代表沒有設定 x。

要求的模式不保證就是實際結果。例如，若一般檔案的群組不符合呼叫者的有效群組或附加群組，且呼叫者沒有必要特權，GNU chmod 可能清除 setgid。作業系統或檔案系統也可能限制 set-ID 的設定。請以 stat 或 ls -l 確認套用後的模式。

目錄的 setgid 不保證新檔案可供群組寫入，仍要確認建立模式、umask 與 ACL。sticky bit 也不保護檔案內容免於讀取或寫入，更不會額外授予目錄的 w/x；它是在原有權限之外增加刪除與重新命名限制。Linux 在 nosuid、no_new_privs 或受到 ptrace 追蹤等條件下，會抑制執行時的 set-ID 身分變更。

為什麼 /tmp 常用 1777？

檔案系統階層標準（FHS）要求 /tmp 可供需要暫存檔的程式使用，但沒有把權限固定為 1777。許多 UNIX 類環境以此模式設定共用暫存目錄。若只給所有人 rwx，其他使用者也可能刪除或重新命名項目；加上 sticky bit，才會受到前述擁有者與特權條件的限制。

縮小需要特權的範圍

由 root 擁有的 setuid 執行檔若有缺陷，可能成為權限提升途徑。setuid 並非一概不適合使用，但必須審查程式實作、擁有者及哪些帳號可修改相關檔案。

• 移除不必要的 setuid 執行檔，確認誰能修改程式與相依項目。
• 在 Linux 上，評估是否只需要特定 capability，例如用於繫結低號碼通訊埠的 CAP_NET_BIND_SERVICE；必要性與設定方式須依服務確認。
• 視用途考慮以 sudo 或 polkit 對個別操作授權。
• 不要依賴 shell 指令稿的 setuid 來設計特權機制；Linux 會忽略指令稿上的 setuid 與 setgid 位元。

OpenSSH 拒絕權限過寬的私鑰

載入私鑰時，可能看到下列英文警告。警告文字保留程式原樣，方便與實際畫面比對：

$ ssh -i ~/.ssh/id_rsa user@host
WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for '/home/user/.ssh/id_rsa' are too open.

常見處理方式是 chmod 600 ~/.ssh/id_rsa。400 會再移除擁有者的寫入位元，但不會阻止擁有者再次變更模式。

在 UNIX 類系統上，OpenSSH portable 會檢查私鑰是否由執行 ssh 的使用者擁有；若是，且群組／其他使用者的任一權限位元有設定，就會拒絕載入該私鑰。這不代表整個用戶端一定停止，仍可能嘗試其他金鑰或驗證方式。這也不是建議改用他人擁有的私鑰；Windows 以 ACL 判定的情況應另行區分。

~/.ssh 建議使用 700，但不是唯一可能值

OpenSSH 文件建議 .ssh 目錄只讓擁有者存取。也應檢查擁有者、群組／其他使用者的寫入權限，以及伺服器端的 StrictModes。用戶端載入私鑰與伺服器端的檢查是不同機制。

服務無法執行程式

由作業系統直接啟動的 CGI 指令稿或執行檔，需要讓實際執行帳號具有 x 權限。若把指令稿當作引數交給直譯器，則需要讀取權限，而不是依賴指令稿自身的 x。先確認 CGI 或後端服務的帳號，例如 www-data，再判斷它適用擁有者、群組還是其他使用者的權限。755 只是範例，不是所有部署的必要值。

取出 Git 檔案後，指令稿無法執行

對一般檔案而言，Git 記錄的是「是否可執行」，不是完整保存擁有者、群組與全部權限。檔案系統的支援程度及 core.fileMode 設定會影響執行位元的處理。在 UNIX 類工作目錄中，chmod u+x script.sh 會為實際檔案增加擁有者的執行權限。

git update-index --chmod=+x script.sh 則是變更索引（index）中的可執行旗標，不會直接修復工作目錄裡檔案的模式。若要透過 Git 分享這項變更，還需要建立提交（commit）。

請分開記住這兩個計算方式：

後三位各自計算：讀取 (4) + 寫入 (2) + 執行／搜尋 (1)
最前面的特殊位數：setuid (4) + setgid (2) + sticky (1)

755 讓擁有者有 rwx，群組與其他使用者可讀取及執行／搜尋；644 讓擁有者可讀寫，其餘可讀取；600 的一般權限只允許擁有者讀寫。這些數字描述的是模式位元，不包含所有可能影響存取的機制。

權限計算機可以協助在八進位與符號表示之間轉換，但使用前仍須確認目標路徑、作業系統規則及實際套用結果。請依工作需求選擇最小必要權限，不要把 777 當成通用解法。