SPECIFICATION

第 7 章：資源存取模式

本章定義 Resource_Access_Mode 的語意、讀寫鎖矩陣、約束條件套用和與 Session 權限的關係。本章對應藍圖 §2.5 的設計意圖。

7.1 模式定義

CAP 協議定義 4 種存取模式：

AccessMode = enum["read", "write", "execute", "configure"]

7.1.1 read

語意：對 Terminal_Resource 進行唯讀存取，不修改資源狀態。

典型操作：

讀取感測器即時資料（溫度、濕度、定位）
檢視媒體檔案（照片、影片）
查詢裝置狀態屬性（電量、連線狀態）

並行性：可共享。多個 Session MAY 同時持有同一資源的 read 模式存取權。

7.1.2 write

語意：對 Terminal_Resource 進行資料寫入或狀態修改。

典型操作：

寫入檔案到儲存裝置
修改裝置的執行參數（音量、亮度、溫度設定）
向應用視窗傳送內容輸入

並行性：排他。同一資源在同一時刻最多有一個 Session 持有 write 模式。

7.1.3 execute

語意：對 Terminal_Resource 觸發執行操作指令。

典型操作：

啟動應用程式
觸發硬體操作指令（拍照、起飛、列印）
呼叫 RPC 介面

並行性：排他。

write 與 execute 的區別：write 修改資料狀態，execute 觸發動作（即使兩者最終都改變狀態）。終端的存取控制粒度可能無法嚴格區分兩者，此時實作 MAY 將 execute 視為 write 的子類（持有 write 權限自動具備 execute 能力）。但本規範的預設語意是兩者獨立——持有 execute 權限不自動取得 write 權限，反之亦然。

7.1.4 configure

語意：對 Terminal_Resource 進行系統級配置變更。

典型操作：

修改裝置的硬體參數（攝影機解析度、網路 SSID）
調整安全策略（防火牆規則、配對設定）
變更資源的存取策略（如 Handover_Policy 配置）

並行性：排他且高權限。configure 通常需要更高級別的授權才能行使（參見 §7.4.3）。

7.2 讀寫鎖矩陣

讀寫鎖矩陣定義同一資源在不同模式下的相容性。新請求與現有佔用的相容性如下：

現有佔用 \ 新請求	read	write	execute	configure
無	✓	✓	✓	✓
read（≥1 個）	✓	✗	✗	✗
write	✗	✗	✗	✗
execute	✗	✗	✗	✗
configure	✗	✗	✗	✗

✓：相容,新請求被允許立即建立 Session。 ✗：不相容，新請求被拒絕（返回 E_RESOURCE_BUSY）。

7.2.1 矩陣語意說明

read 之間相互相容：多個唯讀 Session 可並行存在
write/execute/configure 之間任意兩兩不相容：任意排他模式佔用資源時，其他排他模式請求被拒絕
read 與排他模式互斥：read 佔用時禁止排他請求；排他佔用時禁止 read 請求

7.2.2 終端的處理

終端在處理 AuthRequest 時 MUST：

在校驗通過後、Session 進入 creating 之前，按矩陣檢查相容性
不相容時直接返回 E_RESOURCE_BUSY，不自動排入佇列等待
iFay_Runtime 可選擇重試或發起交接請求（參見第 6 章）

7.3 與 Session 權限的關係

7.3.1 權限清單

每個 Session 在建立時攜帶一個 granted_modes 清單（參見 §2.5），清單內容來自 Authorization_Descriptor.grants 或 Trusted_Ticket.grants 中比對的 Grant.modes。

Fay 透過該 Session 操作資源時，僅能使用 granted_modes 中包含的模式
iFay_Runtime 在 AuthRequest 中指定的 access_mode MUST 是 Grant 授權清單的子集

7.3.2 最小權限原則

iFay_Runtime SHOULD 在 AuthRequest 中僅請求目前任務必需的最低權限模式。例如，僅需讀取資料時請求 read，而不是 read + write。

簽發方 SHOULD 在 Authorization_Descriptor 中按最小權限原則授權，避免不必要的權限放寬。

7.3.3 模式間無階層包含

CAP v1 中各存取模式相互獨立，無階層包含關係：

持有 configure MUST NOT 自動取得 read / write / execute 能力
持有 write MUST NOT 自動取得 read 能力
每種存取模式 MUST 獨立授權

實作 MUST NOT 自動擴充授權範圍。

7.3.4 權限不可提升

Session 建立後，其 granted_modes MUST NOT 在生命週期內提升。若 Fay 需要更高權限的模式：

iFay_Runtime 主動釋放目前 Session
發起新的 AuthRequest，使用具備所需模式的憑證
終端按完整流程建立新 Session

實作 MUST NOT 提供任何「權限升級」的執行時介面。

7.4 約束條件套用

Grant.constraints 是簽發方對授權的附加限制條件。本規範定義以下標準約束鍵，實作 MUST 支援。MAY 支援自訂約束（自訂約束的語意由簽發方與終端協商，但 MUST 在 schema 文件中宣告）。

7.4.1 時間視窗約束

constraints["time_window"] = "08:00-22:00"           // 每日 8:00-22:00 有效
constraints["time_window_tz"] = "Asia/Shanghai"     // 時區，預設 UTC

校驗時機：在 §3.3.2 第 6 步檢查每個 Grant 是否滿足約束。目前時間不在視窗內 → Grant 不比對。

7.4.2 頻率限制約束

constraints["max_calls_per_hour"] = "60"
constraints["max_calls_per_day"]  = "1000"

終端 SHOULD 維護每個 (descriptor_id, fay_id, resource_id) 組合的呼叫計數。超過限制時 → Grant 不比對（返回 E_RATE_LIMIT_EXCEEDED）。

7.4.3 高敏感模式約束

constraints["require_human_confirmation"] = "true"

當 access_mode == "configure" 或滿足該約束的其他場景，終端 MUST 在 Session 建立前向人類使用者請求一次性確認。確認 UI 與 §6.4.3 共享同一通道。

7.4.4 地理圍欄約束

constraints["geo_fence"] = "geohash:wx4g0bm"        // 僅在指定地理範圍內有效
constraints["geo_fence_radius_m"] = "1000"

終端的位置來源 SHOULD 使用經過校準的 GPS 或網路定位。位置不可用時 → Grant 不比對（保守拒絕）。

7.4.5 未識別約束的處理

終端遇到未識別的 constraints 鍵時 MUST：

預設拒絕該 Grant（保守原則）
返回 E_UNSUPPORTED_CONSTRAINT 並附帶未識別的鍵名

簽發方在使用自訂約束時 SHOULD 透過其他管道告知終端約束語意，避免授權失敗。

7.5 模式與 OS 存取控制的對映

終端透過作業系統的存取控制介面實施 access_mode 的執行。本節定義模式到 OS 控制的推薦對映。具體實作可因平台不同而有差異，但 MUST 保持語意等價。

資源類型	read	write	execute	configure
檔案/目錄	檔案系統讀權限	檔案系統寫權限	執行權限	元資料修改權限
裝置檔案	裝置讀	裝置寫	ioctl/控制介面	裝置配置暫存器
應用程序	查詢狀態	輸入注入	啟動/呼叫	修改啟動參數
網路資源	接收資料	傳送資料	建立連線	修改路由/防火牆
攝影機	讀取畫面	不適用	拍攝/錄製控制	調整解析度/影格率

平台特定的存取控制機制（如 SELinux、AppArmor、macOS Sandbox、Android Permission）由終端實作選擇並整合。

7.6 模式更換的約束

同一 (Session, Resource) 在生命週期內 MUST 維持初始的 access_mode 不變。模式更換透過新 Session 實作：

釋放目前 Session
建立新 Session 時指定新 access_mode
終端按矩陣重新評估資源佔用相容性

終端 MUST NOT 提供「模式切換」的執行時介面。

7.7 資源存取的可觀測性

終端 SHOULD 記錄每次資源存取的關鍵資訊（用於稽核）：

session_id
fay_id
resource_id
access_mode
操作類型（如讀取大小、寫入位元組數）
時間戳記

具體稽核日誌格式不在本規範範圍內（參見藍圖 §3.2 排除項「稽核日誌標準化格式」）。

7.8 模式語意的邊界

7.8.1 read 模式不阻止資源被並行修改

read 模式僅授權「讀取」權限，並不保證讀取過程中資源不被其他控制方修改：

多個 read Session 之間互不干擾，但若資源處於「無活躍 Session」狀態時被人類使用者直接操作（繞過 CAP 協議），read Session 仍可能讀到變化的資料
read 模式不提供交易一致性保證

7.8.2 write 模式的原子性

write 模式僅在協議層提供「同一時刻最多一個 write Session」的保證。具體寫操作的原子性（如部分寫入失敗）取決於資源底層語意，不在 CAP 協議範圍內。

7.8.3 execute 模式的副作用

execute 模式觸發的操作 MAY 改變資源狀態。Fay 透過 execute 觸發的副作用由該 Fay 負責。CAP 協議不提供 execute 操作的回滾能力。

7.9 完整決策流程

終端在處理資源存取的完整決策流程：

[AuthRequest 到達]
        │
        ▼
  ┌─────────────────────┐
  │ §3 / §4 憑證校驗    │
  └──────┬──────────────┘
         │ 通過
         ▼
  ┌─────────────────────┐
  │ §7.4 約束條件評估   │
  │ （constraints）     │
  └──────┬──────────────┘
         │ 通過
         ▼
  ┌─────────────────────┐
  │ §7.2 讀寫鎖矩陣檢查 │
  └──────┬──────────────┘
         │ 相容
         ▼
  ┌─────────────────────┐
  │ §5.2 建立 Session   │
  └──────┬──────────────┘
         │
         ▼
  ┌─────────────────────┐
  │ §7.5 OS 存取控制    │
  │     下發            │
  └──────┬──────────────┘
         │
         ▼
  [返回 AuthResult granted]

任一步驟失敗均返回對應錯誤碼並不進入後續步驟。