主控台是一種特權：為什麼它需要自己的權限

主控台看起來像一個畫面。開啟它，出現一個視窗，裡面有文字捲動。感覺就像只是在看而已。

但主控台其實是 shell。而伺服器上的 shell，是那台機器上最高的權限。

兩種不同的權力

變更設定。能做介面允許的事。界限很清楚，因為界限是由介面劃定的。

開啟 shell。什麼都能做。包括介面會拒絕的事，以及介面從來沒聽過的事。

這兩種權力並不互相包含。擁有其中一種不需要另一種，更重要的是：授予其中一種，不應該代表也授予了另一種。

這個區別是真實的，內建角色就看得出來

Proxmox 把主控台綁定在它自己獨立的權限上，而不是一般的變更權限。從內建角色就能看出這是真的：系統管理員角色帶有稽核、主控台和記錄權限，卻不含任何變更權限。

所以，給某人開啟主控台的權利，卻不給變更設定的權利，是正當的設定方式。反過來也一樣。

讓這件事變得重要的常見情況

Proxmox 允許建立自訂角色，而像這樣的角色非常常見：一位能變更網路設定、卻不該碰到伺服器 shell 的操作人員。

這是合理的要求。編輯網路設定，和在伺服器上隨意執行任何指令，不是同一回事。

但如果一個產品的邏輯是既然能變更，也就能開啟主控台，它就會在不知不覺中交給那位操作人員一個 root shell。在 Proxmox 裡拿不到的東西，透過面板就拿到了。

由此得出的一般原則

權限模型必須照抄平台本身的定義，而不是換句話說。

一道只做到大致相同的檢查，在一般的配置上運作正確，也沒有人會注意到。缺口會在某個不尋常的角色被建立的那天打開。而那一天到來時，沒有人記得多年前寫下的那個近似值。

檔案存取也適用同樣的標準

還有一個細節，因為它常被忽略：存取伺服器的檔案系統等同於 shell，即使是唯讀也一樣。

原因很簡單：密碼檔、金鑰和叢集機密都放在那個檔案系統上。擁有唯讀權限、又能讀取檔案的人，早已能得知一切。

所以檔案存取不能用僅供查看的權限來授予；它要求的標準和 shell 相同。

Atlas 的做法

在 Atlas 中，主控台、遠端 shell 和檔案存取都只綁定在主控台權限上。單靠變更權限，無法開啟這些功能。

以前並非一直如此，而本文必須誠實地收尾：這些功能過去也接受變更權限。程式碼中的註解說的是對的，寫著對應的是主控台權限，但程式碼做的卻是另一回事。

這是透過對照 Proxmox 本身的定義實際測量才發現的，並且已經修正。測量結果很清楚：Proxmox 只把 shell 綁定在主控台權限上，不接受變更權限。

實際的嚴重程度也應該如實說明：在內建角色下無法被利用，因為唯一含有變更權限的內建角色，同時也有主控台權限。風險在於自訂角色，也就是上面描述的網路操作人員那個例子。

由此得出的教訓也適用於產品本身：註解正確，不代表程式碼正確。兩者必須分開測量。