P1 檢查結果：系統設定表的完整路徑

檢查日期 2026-09-15｜掃描耗時 2 小時 39 分｜對應卡片 CM-1804｜掃描範圍 jedi-system-core 套件 24 個檔

---

讀取系統設定的三個入口只檢查「你有沒有登入」、完全不檢查權限，任何一個最低權限的員工帳號都能把物件儲存（放所有客戶上傳檔案的地方）的帳號密碼抓走——而同一支檔案裡，寫入類的四個入口每一個都有權限檢查，證明這裡本來就該有。

---

「系統設定」是一張資料表，存的是這套系統要連到外面時用的連線資訊——寄信伺服器、公司目錄服務（LDAP）、放檔案的物件儲存。這些設定裡有帳號也有密碼。

這一棒把這張表從「網路上打得到的入口」一路追到「資料庫」，要回答三個問題：

1. 讀設定的時候，密碼會不會被送出去或寫進日誌檔？
2. 誰改得動、誰讀得到這些設定？
3. 一個客戶碰得到別的客戶、或碰得到平台層的設定嗎？

檢查的是 jedi-system-core 這支套件的 24 個檔——這支是「起手式五支」之一，每個新客戶裝上就有，所以這裡的洞是全產品範圍。

---

這兩條是連在一起的：問題 1 是「誰都進得來」，問題 2 是「進來之後看到的是明文」。單看問題 2 只是「管理員的瀏覽器裡有密碼」，影響有限；配上問題 1，就是任何人都能直接讀到明文密碼。

---

問題 1：讀設定不檢查權限（高）

現況：已修（M22-2，CM-2063）

白話：系統設定這張表有七個對外入口。寫入類的四個（新增、修改、刪除、還原預設）每一個都會檢查「你有沒有改這組設定的權限」，讀取類的三個一個都沒有，只檢查「你有沒有登入」。

首腦自己打開檔案核對（不是採信報告）：

jedi_system_core/api/routes/system_config_route.py

第 38-41 行   依群組取清單   只有「要登入」            ← 沒有權限檢查
第 53-56 行   依編號取單筆   只有「要登入」            ← 沒有權限檢查
第 63-71 行   修改           要登入 ＋ assert_config_capability(..., "update")
第 78-84 行   刪除           要登入 ＋ assert_config_capability(..., "delete")
第 105-110 行 新增           要登入 ＋ assert_config_capability(..., "create")

同一支檔案裡就有反例——這證明「讀取這裡本來就該有權限檢查」不是猜測，是漏掉了。

而且檔案自己寫了出來。第 30-34 行那段說明文字白紙黑字：

「無寫入守門——讀取只要登入即可；受 RLS 與宿主包過的 service 兩層限制（別的租戶的列看不到、出廠快照列不存在）。」

（RLS 就是資料庫層「每個客戶只能看到自己資料」的隔離機制。）

但那兩層限制擋不住這件事。RLS 擋的是「看到別的客戶的列」，它不擋「看自己客戶的那一列」——而問題就在自己那一列裡面：

• 安裝程式 scripts/installer/install.sh:1885-1908 的 configure_storage_config_row，把內建物件儲存的 access_key 和 secret_key 寫進這一列。
• 每建一個新客戶，app/system_config/service/tenant_storage_config_seeder.py:52 的 seed_from_root() 會把 ROOT 那一份逐字複製給新客戶。

所以每個客戶自己那一列裡放的，是同一組全域共用的密鑰。RLS 認真擋住了「看別人的列」，但每個人自己的列裡裝的都是同一把鑰匙。

攻擊情境很簡單：

1. 用任何一個普通員工帳號登入，拿到登入憑證。
2. 打 GET /api/1.0/system/configs/STORAGE_CONFIG。
3. 回傳內容裡 data[0].value 直接含伺服器位址、儲存空間名稱、access_key、secret_key。
4. 拿這組帳密直連物件儲存，所有客戶上傳的檔案與框架檔可讀可寫。

「沒有權限檢查」在三個地方，不是一個：套件內的清單（:41）、套件內的單筆（:56），以及主專案自己保留的那支 GET /system/config/<group>/<key>（compliance-manager-be/api/system_config/routes/system_config_route.py:131，也只掛 @jwt_required()）。三個都要補，補一個沒有用。

怎麼修：讀取端比照寫入端補上按群組分流的檢查——

• 清單：assert_config_capability(group, "read")，群組從網址上拿。
• 單筆：assert_config_capability(service.resolve_group_for_uid(uid), "read")，跟同檔修改／刪除的寫法一模一樣。
• 主專案那支：同檔第 103 行對「還原預設」已經用過 assert_config_capability("STORAGE_CONFIG", "read")，形狀照抄即可。

需要的能力點已經存在、不用新建：主專案 core/plugins/system_core.py 的 _GROUP_CAPABILITY_RESOURCE 已經有 storage-config / smtp-config / ldap-config 的對應，storage-config.read 這類能力點在 04-seed-core.sql 也已經 seed 過。這是接線，不是造新東西。

⚠️ 修的時候要注意順序：同檔第 68-70 行有一段註解說明「先 403 再 404」不可對調——查不到群組時 resolve_group_for_uid 回 None，宿主的守門對 None 會退回最嚴的權限。讀取端補守門時要沿用同樣的順序，否則沒權限的人可以用不存在的編號試探出「這筆存不存在」。

問題 2：遮罩名單漏掉物件儲存（低）

現況：已修（M22-3，CM-2054）

白話：系統本來有一道「回傳設定前先把密碼欄位刪掉」的遮罩機制。這道機制靠兩份名單決定要遮什麼，兩份都漏掉了物件儲存。

首腦自己打開檔案核對：

jedi_system_core/plugin/contract.py

第 61 行  要遮罩的群組：SMTP、THIRD_PARTY_LOGIN、NOTIFY_CONFIG、ISSUE_INTEGRATE_CONFIG
                       ↑ 沒有 STORAGE_CONFIG

第 65 行  要遮罩的欄位名：secret、private_token
                       ↑ 沒有 secret_key（物件儲存實際用的欄位名就叫這個）

兩份名單都漏，所以物件儲存的密鑰在遮罩這關是完全透明的——不是遮得不夠，是根本沒進遮罩的視野。

寄信和 LDAP 是怎麼做的：密碼從來不回傳，前端要表示「密碼沒改」就送 changePwd=false，後端沿用舊的（機制在 domain/service/system_config_domain_service.py 的 _preserve_existing_secret）。儲存設定沒有跟上這套做法，於是同一把共用密鑰散落在每個客戶管理員的瀏覽器裡。

怎麼修：

1. STORAGE_CONFIG 加進第 61 行的群組名單。
2. secret_key、minio_secret_key 加進第 65 行的欄位名單。
3. 儲存設定頁改用跟寄信／LDAP 一樣的 changePwd 做法（不回密鑰、沒帶就沿用），現成機制已經有了。
4. 記得同步改測試：tests/unittest/test_plugin_contract.py:311-313 有一條斷言把現在這份名單釘死了，不改會紅。

⚠️ 這是有意識的契約變更，不是單純補漏：第 59-60 行的註解明寫這份名單「凍結」。動它之前要確認沒有別的地方依賴現在這份名單的內容。

---

派工卡列了八個要追的點。掃描與首腦核對後的結果：

要特別講的是第①點與第②點：兩條都對上了總表既有的舊發現，這一棒確認了源頭就在這張表，不必再從下游一條一條撿。

---

分兩層講，這兩層的答案不一樣。

「這兩條是真的嗎」→ ✅ 可信

工具給出的驗證章是 verified（完整通過，不是 unverified）。兩條發現都是三個獨立檢查員投票、三票全過。

而且檢查員真的在做對抗性判斷，不是橡皮圖章——研究員總共提了四條，兩條被一致否決（上表第④、⑦點那兩條），否決理由具體到打開檔案指出「實體只有六個欄位、多送會報錯」「同一個數值在另外兩處也是預設值」。否決率一半。

首腦也沒有只採信工具，兩條都自己開檔核對：

• 問題 1：打開 system_config_route.py 第 30-110 行，確認讀取的兩個方法確實只有 @auth_required、寫入的三個方法確實都有 assert_config_capability，檔案自己的說明文字也承認「讀取只要登入即可」。另外自己去查了主專案的 _host.py:208，確認 auth_required 被填進去的就是光禿禿的 jwt_required()。
• 問題 2：打開 contract.py 第 55-66 行，確認第 61 行就是那四個群組、第 65 行就是那兩個欄位名，上面的註解確實寫了「凍結」。
• 共用密鑰那條因果鏈：自己打開 install.sh:1885-1908 確認安裝程式把密鑰寫進那一列，打開 tenant_storage_config_seeder.py:52 確認新客戶是逐字複製 ROOT 那份。這條鏈是「為什麼 RLS 擋不住」的關鍵，是首腦自己串的，不是報告給的。

「是不是只有這兩條」→ ❌ 不可信

三個原因：

1. 這是快篩模式（low）。只派一個研究員讀完全部 24 個檔，沒有做全面盤點、沒有做威脅建模。它找的是「讀下來最明顯的東西」，不是「窮舉所有可能」。
2. 卡片點名的八項裡，有三項（③⑦部分、⑧）掃描根本沒提出來。沒提出不等於查過沒問題——以這個模式的深度，更可能是沒追到那一層。這三項若要有結論，需要人工另外追。
3. 範圍只有這支套件的設定那一半。主專案的接線（第 2 棒）、選單字典（第 3 棒）都不在這次範圍內。特別是問題 1 已經證明主專案那支 /system/config/<group>/<key> 也有同樣的洞，那支正是第 2 棒的範圍——這暗示第 2 棒很可能還有同類問題。

還有一點要講明：整個掃描過程沒有執行任何程式碼。沒有跑測試、沒有真的送出那個請求、沒有真的去連物件儲存。所有結論都是「讀程式碼推出來的」。上面講的密鑰內容，是從安裝程式和複製程式的程式碼推出來的，不是從哪個資料庫裡讀出來的。

---

想自己確認問題 1，照這個順序做（只讀不改，不會動到任何環境）：

1. 開 jedi-system-core/jedi_system_core/api/routes/system_config_route.py，看第 38-41 行（讀清單）和第 63-71 行（修改）。對比兩者的裝飾器：前者只有 @auth_required，後者多一行 assert_config_capability。
2. 看同檔第 30-34 行的說明文字，確認它自己承認「讀取只要登入即可」。
3. 開 compliance-manager-be/api/system_config/routes/system_config_route.py，看第 131 行那支 GET，確認也只有 @jwt_required()；再看第 103 行的「還原預設」，那支有 assert_config_capability("STORAGE_CONFIG", "read")——同一支檔案裡的正反例。
4. 開 scripts/installer/install.sh 第 1885-1908 行，確認安裝時把 access_key／secret_key 寫進 STORAGE_CONFIG 那一列。
5. 開 app/system_config/service/tenant_storage_config_seeder.py 第 52 行起，確認新客戶是複製 ROOT 那份。

想確認問題 2：開 jedi-system-core/jedi_system_core/plugin/contract.py 第 55-66 行，數一下第 61 行那四個群組名稱裡有沒有 STORAGE_CONFIG，第 65 行那兩個欄位名裡有沒有 secret_key。

---