一款嚴格的 chmod 計算機替代方案必須能在 4,096 個值的空間中,將從八進位 0000 到 7777 的每一個模式完整轉換,驗證輸入時不進行猜測,並保留特殊位元 s、S、t 和 T 的大小寫。一般八進位數字遵循固定的公式:讀取貢獻 4,寫入貢獻 2,執行或目錄搜尋貢獻 1,因此每個位置的總和為 0 到 7。四位數模式會在最前面加上特殊位元數字,其中 setuid 為 4,setgid 為 2,sticky 為 1。只能對應像 755 或 644 這類常見數值的計算機,將會默默地拒絕或錯誤回報不常見的模式。Lizely 的 Chmod Calculator 僅接受剛好三個或四個 ASCII 八進位數字,或剛好九個有效的符號字元,測試從 0000 到 7777 的每一個模式,並依據對應的執行位元是否也設定,來呈現特殊位元字母的小寫或大寫形式。所有處理都在瀏覽器分頁中執行,因此沒有任何權限值、檔案路徑或指令會離開你的機器。
任何管理 Unix 或 Linux 系統的人都會經常碰到模式位元,因此會想要一個可靠的轉換器。問題在於,大多數線上 chmod 計算機只做表面的工作:它們列出少數幾個眾所皆知的模式,如 644、755 和 777,接受格式寬鬆的輸入,並悄悄地截斷任何不尋常的內容。當部署腳本引用像 4750、2640 或 1777 這類不常見的組合,或伺服器檢查清單要求目錄上 setgid 必須開啟的精確四位數值時,這種習慣會造成真正的摩擦。一個無法精準表示那些模式的計算機,實際上並不是真正的替代方案;它只是一張不完整的參考卡。
常見 Chmod 計算機的不足之處
最常見的落差在於寬鬆的輸入處理。許多計算機會欣然接受像 "0o755"、"-rwxr-xr-x" 或 "u+x" 這類字串,接著要嘛當機、傳回空結果,要嘛默默地選用預設值。這種模糊性對權限工作而言很危險,因為缺少一個位元就會改變誰能讀取或寫入檔案。Chmod Calculator 會直接拒絕那些形式。八進位輸入必須剛好包含三個或四個 ASCII 八進位數字,不能有前綴、符號、空白、分隔符、小數點、底線或 Unicode 相似字元。符號輸入必須剛好是九個位置有效的字元,且不能包含前導的檔案類型破折號或修改運算式。
第二個落差是覆蓋範圍不完整。一個只測試少數幾個常見範例的計算機,可能通過一般性使用,卻在長尾情境中失效。Lizely 的實作會徹底檢查從八進位 0000 到 7777 的每一個值,也就是涵蓋完整 12 位元範圍的 4,096 個獨立模式,符合 POSIX 對檔案權限的定義。這種覆蓋範圍很重要,因為 4755 與 4750 之間的差異,就是「任何人都能執行的程式」與「只有擁有者與群組才能執行的程式」之間的差別,而有瑕疵的轉換器可能會在毫無警訊的情況下將兩者調換。
若想在你轉換權限列表之前先深入了解如何閱讀它們,如何尋找並轉換檔案的 chmod 值 這份逐步指南與計算機搭配使用效果絕佳。
嚴格的八進位對符號轉換是什麼樣子
嚴格的轉換從完整的輸入快照開始,並產生三個配對的檢視:正規化八進位、九個字元的符號字串,以及 owner、group 與 others 的逐位元表格。每個一般位置是讀取、寫入與執行貢獻的總和。下表摘要了每一個遵循 POSIX 定義的 chmod 計算機所使用的數值。
| 八進位數字 | 加入的位元 | 產生的權限集合 |
|---|---|---|
| 0 | 無 | --- |
| 1 | 僅執行 | --x |
| 2 | 僅寫入 | -w- |
| 3 | 寫入與執行 | -wx |
| 4 | 僅讀取 | r-- |
| 5 | 讀取與執行 | r-x |
| 6 | 讀取與寫入 | rw- |
| 7 | 讀取、寫入與執行 | rwx |
當出現第四個數字時,它的意義就完全改變了。4755 的第一個數字並非額外的權限位元;它是一個特殊位元指示器,其中 setuid 加入 4,setgid 加入 2,sticky 位元加入 1。其餘三個數字仍代表 owner、group 與 others。計算機透過從正規化輸出中省略零的特殊數字來保留這個區別,因此 0755 會被回報為 755,而 4755 則會保留前導的 4。
使用 Chmod Calculator 正確轉換模式
此計算機遵循嚴格的三步驟工作流程,避免無效的輸入產生誤導性的結果。
- 選擇方向並輸入完整的快照。選擇八進位對符號,或符號對八進位。如果你從八進位開始,請輸入剛好三個數字(例如 755),或剛好四個數字(例如 4755)。如果你從符號開始,請輸入剛好九個字元(例如 rwxr-xr-x 或 rwsr-xr-x)。其他輸入都會回傳語法錯誤。
- 轉換並檢視全部三種檢視。閱讀正規化八進位、九個字元的符號字串,以及 owner、group 和 others 的表格。確認 setuid、setgid 與 sticky 的列只有在對應位元設定時才出現,並檢查小寫或大寫字母是否符合「執行位元也必須存在才會出現小寫結果」的規則。
- 仔細檢視後再複製 chmod 樣板。確認目標檔案、目前擁有權、特殊位元預期,以及實際使用者或服務的最小權限姿態。剪貼簿輸出是一個 chmod OCTAL FILE 樣板,其中 FILE 是預留位置;此工具絕不會要求、解析或對真實路徑執行任何操作。
編輯輸入或切換方向會清除先前的所有結果、錯誤訊息與複製狀態。失敗的驗證無法保留先前的轉換結果,而剪貼簿動作受到產生流程的防護,因此延遲的非同步複製結果不會在輸入或模式變更後發布過時的成功狀態。原始輸入的上限為 32 個 UTF-16 字碼單位;剛好達到上限會收到語法錯誤,而下一個單位則會收到明確的預算錯誤,而不是默默地截斷。
安全地處理 Setuid、Setgid 與 Sticky 位元
特殊位元是多數計算機最容易搞錯的部分,同時也是出錯時安全成本最高的部分。Chmod Calculator 在對應執行位元設定時,將特殊位元的執行位置顯示為小寫 s 或 t;若該位元未設定,則顯示為大寫 S 或 T。保留大小寫對於真正的模式位元往返轉換是必要的;一個總是顯示小寫字母的計算機會遺失像 ls -l 這類工具所顯示的資訊。
| 特殊位元 | 八進位值 | 小寫形式(執行位元設定) | 大寫形式(執行位元未設定) |
|---|---|---|---|
| setuid | 4 | owner 位置顯示 s | owner 位置顯示 S |
| setgid | 2 | group 位置顯示 s | group 位置顯示 S |
| sticky | 1 | others 位置顯示 t | others 位置顯示 T |
四位數模式 6755 同時帶有 setuid 與 setgid,而 7755 則同時帶有全部三個特殊位元。文字 4096 並不是有效的八進位,因為 9 不是八進位數字,而十進位 4096 只超出最大值 7777 一個數字。一個可靠的轉換器會明確說明這些規則,而不是留給讀者自行推敲。特殊位元在操作上也需要小心:可執行檔上的 setuid 與 setgid 會變更有效身分,目錄上的 setgid 通常會影響新建立的子項目之群組,而目錄上的 sticky 通常會限制非擁有者或非目錄擁有者的刪除或重新命名動作。
從計算機輸出到真正的 chmod 指令
轉換後的位元是檢視輔助工具,並非保證。POSIX 定義了位元的位置,但實際存取仍可能受到擁有權、存取控制清單 (ACL)、能力 (capabilities)、掛載選項、唯讀檔案系統、應用程式沙箱化以及其他作業系統政策的影響,而且程序必須擁有穿越上層目錄的權限,才能接觸到檔案本身。計算機回報的是「請求的」模式位元,但無法保證檔案系統會保留或落實每一個位元。想更深入了解該指令本身,GNU chmod 手冊頁面 涵蓋了遞迴套用、符號式修改與參考檔案選項。
將輸出視為多種輸入之一。優先採用滿足實際使用者或服務需求的最小權限,並避免為了規避存取問題就複製像 777 這類過於寬鬆的範例;應先診斷擁有權、群組成員資格、目錄穿越、ACL 與服務身分。Umask 會影響建立檔案時所請求的權限;它並非由轉換器默默套用的額外數字,因此一個設定 umask 022 接著執行 chmod 755 的腳本,所產生的檔案在計算機中仍然會回報為 755。Chmod Calculator 不會執行 chmod、不會遞迴處理目錄、不會跟隨符號連結、不會修改 ACL、不會計算 umask 結果、不會檢查目前權限,也不會判斷所請求的模式對特定程式是否安全,這也正是它的輸出能夠清楚地作為「規劃用的成品」而非「裁決」的原因。對於也想複習讓八進位組合運作的位元運算數學的讀者,MDN 位元 AND 運算參考 記錄了 POSIX 遮罩比較所依據的運算子。
如果你正在權衡各種選項,Cookie Converter API 替代方案:在你的瀏覽器中執行 對此有詳細說明。