情境 15 兩種角色 · 權限設計
跑在套件帳號裡，不碰 root
Syngle 的能力上限就是套件帳號，啟動時看到 root 就拒絕，能力清單是空的，每一條 route 都要求 DSM 管理員
0個 · 需要的 root 權限
權限審查
先問它用什麼身分跑
一個能看到整個機隊的工具，權限邊界要能一句話講完：套件帳號、管理員入口、逐站範圍
- 需要 root 或系統服務嗎
- 套件宣告了哪些能力
- 誰能開這個介面
- 換一個據點，資料會不會看到別的據點
身分、能力、範圍三件事
這三件事不靠目錄資料，也不是 AI 或 MCP 呼叫時才檢查
啟動就拒絕 root
runtime 檢查 effective UID，是 root 就直接拒絕，CGI 和 worker 都跑套件帳號，Agent 也一樣
能力清單是空的
套件宣告的 capabilities 是空的，沒有 delegate 或 rootOps，不裝全機共用 service，也不需要 TUN 或 CAP_NET_ADMIN
每一條 route 都是管理員
541 個方法裡 538 個是 administrators，3 個 integration 只能由套件程序呼叫，缺 handler 就 fail closed
逐站範圍，每次重驗
每個 Ref 都解析回 Org 和 Site，Scope 外一律拒絕，AI 和 MCP 一次只能指定一個 Org
身分護欄是程式碼
I1–I10：只寫本機帳號、不碰 Controller 自己的登入、不移除最後一位 administrator、不動內建帳號和系統群組
你會做到
看套件身分
安裝後確認 Process 使用者和 capabilities，沒有 root，也沒有額外能力
看 route 權限
permissions.json 由產生器輸出，digest 釘在 build 上，不符就拒絕
切換範圍
範圍切換依組織分組，只有一個組織和一個據點時隱藏，每次讀取都重做授權
看身分寫入的護欄
只寫本機帳號，DOMAIN 和 @ 不得進本機 API，移除最後一位 administrator 會失敗
看稽核留下什麼
誰、何時、透過哪個入口、對哪些 Ref、結果，被拒絕的呼叫也會記
權限小，出錯的範圍也小，沒有 root、沒有全機服務，還是看得到完整的機隊