chmod 計算機會在嚴格的 3 位數或 4 位數八進位表示法，以及完整的 9 字元符號快照之間，轉換 Unix 權限位元模式，並明確處理 setuid、setgid 和黏滯位 (sticky bit)。在每個八進位位置上，讀取貢獻 4、寫入貢獻 2，而執行 (或目錄搜尋) 貢獻 1，因此 7 代表讀取、寫入和執行，6 代表讀取和寫入，5 代表讀取和執行，而 0 代表無。三個普通位置依序代表擁有者、群組和其他人。當輸入 4 位數的值時，首位數字結合了 setuid 為 4、setgid 為 2，以及黏滯位為 1，這代表 6755 同時帶有兩個特殊位元，而 7755 則同時帶有全部三個。符號輸出會在共享的實例中保留這些特殊位元:擁有者位置的小寫 s 代表同時設定了 setuid 和擁有者執行，大寫 S 代表設定了 setuid 但缺少擁有者執行，而相同的小寫與大寫規則也適用於群組位置的 setgid 以及其他人位置的黏滯位。完整的 12 位元模式空間包含從八進位 0000 到 7777 共 4,096 個不同的值，而任何值得信賴的計算機都會涵蓋完整範圍，而不是僅處理少數常見的預設值。
Chmod 計算機能做與不能做的事
chmod 計算機是一個小型、具確定性的轉換工具，專門處理一種特定的 Unix 資料類型:12 位元的檔案模式。它僅接受一組嚴格的輸入快照，以及一個 octal-to-symbolic (八進位轉符號) 或 symbolic-to-octal (符號轉八進位) 的方向旗標，並輸出標準的八進位值、9 字元的符號字串，以及一份針對擁有者、群組和其他人的可讀權限表。Chmod 計算機 完全在當前的瀏覽器分頁中執行此轉換，不會將任何路徑、權限值或指令傳送到遠端伺服器。它不是檔案編輯器:它絕不會要求實際的檔案路徑、絕不會呼叫 chmod、絕不會遞迴瀏覽目錄、絕不會檢查目前的權限，也絕不會參考 umask。它唯一的工作，就是精準地描述所要求的模式位元集合，讓你在命令列上套用之前能先行檢視該值，這就是為什麼它的複製動作會輸出一個 chmod OCTAL FILE 樣板，而不是一份完成的指令碼。
八進位數字背後的 4-2-1 數學
每個普通的八進位位置涵蓋一個主體，也就是擁有者、群組或其他人，而每個位置都是一個 3 位元的欄位。這些位元的權重是 2 的冪次:讀取為 4、寫入為 2，而執行 (或目錄搜尋) 為 1。將已啟用的位元相加，即會得到一個介於 0 到 7 之間的數字。這短短的一行，就是 chmod 數字表示法的全部基礎，而任何可靠的計算機都會以明確的位元遮罩來實作它，而不是依賴一張收錄常見範例的小表格。這個模式與其他 Unix 旗標的儲存方式相同，而其底層機制就只是 對遮罩進行位元 AND 運算，如 Mozilla 開發者網路參考文件中所述。
| 數字 | 讀取 (4) | 寫入 (2) | 執行 (1) | 符號 |
|---|---|---|---|---|
| 0 | — | — | — | --- |
| 1 | — | — | 設定 | --x |
| 2 | — | 設定 | — | -w- |
| 3 | — | 設定 | 設定 | -wx |
| 4 | 設定 | — | — | r-- |
| 5 | 設定 | — | 設定 | r-x |
| 6 | 設定 | 設定 | — | rw- |
| 7 | 設定 | 設定 | 設定 | rwx |
由右至左讀取符合 chmod 的傳統:最右邊的位元是執行，然後是寫入，再來是讀取。無論該欄位屬於檔案 (此時執行代表檔案可被叫用) 或目錄 (此時執行代表目錄可被穿越，常被標示為 search 而不是 execute)，這個對應關係都相同。如果你正在解讀 ls -l 輸出中的某個值，三個位置的對照表就已足夠，諸如 0755 的前置零僅代表沒有特殊位元，描述的模式與 755 相同。
讀懂 9 字元的符號輸出
符號輸出永遠剛好包含九個字元:依序為擁有者三個、群組三個、其他三人。每個位置接受 r 或連字號代表讀取，w 或連字號代表寫入，而 x 或連字號代表一般執行。一個接受完整快照的計算機，例如 rwxr-xr-x 或 rwsr-xr-x，會提供一個可往返 (round-trip) 的值，讓你將其貼回工具，便能在不遺失資訊的情況下還原原始八進位數字。相對地，諸如 -rwxr-xr-x 中的前置檔案類型字元屬於 ls -l 而非 chmod，而 u+x 這類修改運算式則帶有不同的資訊，不該被送進轉換模式快照的計算機中。
特殊位元 setuid、setgid 和黏滯位的大小寫，以單一字元編碼了兩項資訊:特殊位元是否設定，以及對應的執行位元是否設定。小寫代表兩者皆設定，大寫代表特殊位元已設定但該執行位置缺席。擁有者位置使用 s 與 S 代表 setuid，其他人位置使用 t 與 T 代表黏滯位，而 setgid 則在群組位置遵循相同的小寫與大寫規則。
| 特殊位元 | 同時設定執行 | 字元 |
|---|---|---|
| setuid (擁有者) | 是 | s |
| setuid (擁有者) | 否 | S |
| setgid (群組) | 是 | s |
| setgid (群組) | 否 | S |
| 黏滯位 (其他人) | 是 | t |
| 黏滯位 (其他人) | 否 | T |
保留該大小寫區分相當重要，因為 chmod 4755 與 chmod 4655 描述了本質上不同的檔案狀態:只有後者在沒有擁有者執行的情況下帶有 setuid，因此若計算機將兩者一律扁平化為 S，將會在往返過程中遺失狀態。
如何使用 Chmod 計算機
- 開啟 Chmod 計算機並選擇方向:若你持有像 754 或 4755 這類數字，請選 octal-to-symbolic;若你持有像 rwxr-xr-x 或 rwsr-xr-x 這類字串，則選 symbolic-to-octal。
- 以工具要求的嚴格格式，輸入剛好一組完整的權限快照:一般模式使用三個 ASCII 八進位數字，含特殊位元時使用四個 ASCII 八進位數字，反向時則輸入九個位置合法的符號字元。請勿加上 0o 前綴、符號、空白、分隔符、底線或前置的檔案類型連字號。
- 閱讀計算機為檢視所產生的標準八進位值、9 字元符號值，以及擁有者、群組和其他人對照表。該表格會區分讀取、寫入和執行 (或搜尋)，並標示任何已設定的 setuid、setgid 或黏滯位。
- 在使用複製按鈕之前，請再次確認目標檔案、其當前擁有者，以及該要求是否確實反映最小權限原則。複製動作會輸出一份 chmod OCTAL FILE 樣板;FILE 是預留位置，你必須在執行指令前將其替換為實際路徑。
- 僅在完成上述檢視後，再於命令列上執行該指令。計算機僅描述所要求的模式位元，並不保證檔案系統在指令執行後會保留或接受每一個位元。
4 位元模式中的特殊位元:setuid、setgid 與黏滯位
三個八進位位置涵蓋一般權限，而第四個前置位置則結合了三個獨立的旗標。setuid 貢獻 4、setgid 貢獻 2，黏滯位貢獻 1。將已啟用的特殊旗標相加，即會得到一個介於 0 到 7 之間的前置數字，這就是為什麼 6755 同時帶有 setuid 與 setgid、4755 僅帶有 setuid、1755 僅帶有黏滯位，而 7755 則同時帶有全部三個。像 755 這樣的 3 位數輸入明確表示沒有任何特殊旗標，而一個在沒有提示的情況下默默將 3 位數輸入提升為 4 位數的計算機，將會改變其意義。GNU chmod 手冊頁 記載了相同的位元位置，在檢視特殊值時值得將其保持開啟。
特殊位元值得在操作上特別留意。可執行檔上的 setuid 與 setgid 可能會變更執行中行程的有效身分，而許多系統會在檔案擁有者與所要求的有效身分不符時，將其清除或忽略。目錄上的 setgid 通常會強制新項目的群組與該目錄的群組一致，這在共享工作樹 (working tree) 中是個實用的模式。目錄上的黏滯位 (常以 /tmp 上的 t 呈現) 會將刪除與重新命名權限限制為該項目的擁有者、目錄的擁有者或 root，這正是讓多位使用者能在同一個全域可寫入的暫存目錄中作業、又不會互相踩踏的實務機制。
嚴格的輸入規則與常見的拒絕情況
一個值得信賴的計算機會強制執行嚴格的輸入文法，以確保結果不含糊。八進位輸入必須剛好是三個或四個 ASCII 八進位數字，不得包含 0o 前綴、符號、前置空白、分隔符、小數點、底線或任何 Unicode 形似數字。像 0755 這樣的前置零會被接受，並代表與 755 相同的模式，因為在沒有設定特殊位元時，標準輸出會直接省略多餘的零。3 位數輸入明確代表沒有 setuid、setgid 或黏滯位;這不是被禁止的數量，而是該值所承載的資訊。符號輸入必須剛好包含九個位置合法的字元，不得包含來自 ls -l 的前置檔案類型連字號，也不得有 u+x 或 g-w 這類修改運算式。兩個方向在原始輸入上共用 32 個 UTF-16 程式碼單位的預算，因此落在邊界的退化值會收到明確的語法錯誤，而下一個程式碼單位則會收到明確的預算錯誤，而不是被靜默地截斷為 HTML。那麼，計算機拒絕一份快照的常見原因，便包括前置的負號、0o 前綴、小數點、內嵌空白，以及帶有來自 ls -l 的前置連字號之符號值。
Chmod 計算機同樣拒絕驗證一份無論如何都會改變結果的快照:編輯輸入會清除任何先前的結果、錯誤與複製狀態，而剪貼簿的完成動作受到世代保護 (generation-guarded)，因此一個延遲的非同步複製動作，不會在輸入或模式已變更後，發布一個過時的成功訊息。
模式是位元，而非授權
chmod 的位元模式是對檔案系統的一個請求，而作業系統可以拒絕其中的部分請求。POSIX 定義了位元的位置，但實際的存取仍會受到擁有者、存取控制清單 (ACL)、能力 (capabilities)、掛載選項（唯讀檔案系統無論模式為何都不會接受寫入）、唯讀檔案旗標、應用程式沙盒化以及其他政策的影響。一個行程也必須擁有權限來遍歷路徑中的每一個上層目錄，才能抵達目標檔案，這就是為什麼對一個位於使用者無法遍歷之目錄中的檔案執行 chmod 777 不會產生任何效果，也無法作為解決方案的原因。Umask 會影響檔案建立時所請求的權限，但它並不是轉換器額外加上的一個數字；如果有計算器具悄悄地從你的輸入中減去 umask，那它就是在對這些位元的意義說謊。
若要更深入地了解具體數值（例如 6755 和 7755），請參閱setuid、sticky 與 rwx 範例指南，或是將八進位與 rwx 速查表開在另一個分頁裡以便對照。在套用指令前，請將計算器的輸出視為一項檢查，盡可能採用實際使用者與服務所需的最少權限，並避免複製像 777 這類過於寬鬆的範例來規避存取問題；請先診斷擁有權、群組、目錄遍歷、ACL 以及服務身分等事項。