# 38.5\. 規則和權限 由于PostgreSQL規則系統對查詢的重寫， 非初始查詢指定的其它表/視圖被訪問。使用更新規則的時候，這可能包括對表的寫權限。 重寫規則并不擁有一個獨立的所有者。關系(表或視圖)的所有者自動成為重寫規則的缺省所有者。 PostgreSQL規則系統改變缺省的訪問控制系統的特性。 因規則而使用的關系要對定義規則所有者進行權限檢查，而不是激活規則的用戶， 這意味著一個用戶只需要對他的查詢里明確指定的表/視圖擁有所需的權限就可進行操作。 例如：某用戶有一個電話號碼列表，其中一些是私人的，另外的一些是辦公室秘書需要的。 他可以用下面方法構建查詢： ``` CREATE TABLE phone_data (person text, phone text, private boolean); CREATE VIEW phone_number AS SELECT person, CASE WHEN NOT private THEN phone END AS phone FROM phone_data; GRANT SELECT ON phone_number TO secretary; ``` 除了他以外(還有數據庫超級用戶)沒有人可以訪問`phone_data`表。 但因為`GRANT`的原因，秘書可以從`phone_number` 視圖上運行`SELECT`。規則系統將把從`phone_number` 里的`SELECT`重寫為從`phone_data`里的 `SELECT`。因為用戶是`phone_number`的所有者， 因此也是規則的所有者，所以現在要檢查他對`phone_data`的讀訪問的權限， 而這個查詢是被允許的。同時也要檢查訪問`phone_number`的權限， 但這是對一個被撤消權限的用戶進行檢查的，所以除了用戶自己和秘書外沒有人可以使用它。 權限檢查是按規則逐條進行的。所以此時的秘書是唯一的一個可以看到公共電話號碼的人。 但秘書可以設立另一個視圖并且賦予該視圖公共權限。這樣， 任何人都可以通過秘書的視圖看到`phone_number`數據。 秘書不能做的事情是創建一個直接訪問`phone_data`的視圖(實際上他是可以的， 但沒有任何作用，因為每個訪問都會因通不過權限檢查而被踢出事務)。而且用戶很快會認識到， 秘書開放了他的`phone_number`視圖后，他還可以撤消他的訪問權限。這樣， 所有對秘書視圖的訪問馬上就失效了。 有些人會認為這種逐條規則的檢查是一個安全漏洞，但事實上不是。如果這樣做不能奏效， 秘書將必須建立一個與`phone_number`有相同字段的表并且每天拷貝一次數據進去。 那么這是他自己的數據因而可以賦予其它人訪問的權力。一個`GRANT` 意味著"我信任你"。如果某個你信任的人做了上面的事情， 那你就該想想是否該`REVOKE`了。 請注意，當視圖可以用來隱藏使用了上面的技術的特定的內容時， 它們不能用來可靠地隱藏在不可視的行的數據，除非已經設置了`security_barrier` 標志。例如，下面的視圖是不安全的： ``` CREATE VIEW phone_number AS SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%'; ``` 這個視圖可能看起來是安全的，因為規則系統將重寫`phone_number`里面的任意 `SELECT`到`phone_data`里面的`SELECT`， 并且添加只有不是以412開頭的`phone`才是所需要的條目的條件。 但是如果用戶可以創建他或她自己的函數，那么使規劃器在`NOT LIKE` 表達式之前執行用戶定義的函數也不困難。例如： ``` CREATE FUNCTION tricky(text, text) RETURNS bool AS $$ BEGIN RAISE NOTICE '% => %', $1, $2; RETURN true; END $$ LANGUAGE plpgsql COST 0.0000000000000000000001; SELECT * FROM phone_number WHERE tricky(person, phone); ``` `phone_data`表里的每個人和電話號碼將作為一個`NOTICE`打印， 因為規劃器將在更多的昂貴的`NOT LIKE`之前執行 廉價的`tricky`函數。即使阻止了用戶定義新的函數， 內建的函數可以用在類似的安全系統里。（例如， 大多數轉換函數在他們產生的錯誤信息中包含他們的輸入值。） 類似的注意事項應用于更新規則。在上一章的例子里，例子數據庫里的表的所有者可以把 `shoelace`視圖的`SELECT`, `INSERT`, `UPDATE`, `DELETE`權限賦予其他人。但對`shoelace_log`只有`SELECT`權限。 寫日志記錄的規則動作仍然可以成功的執行。并且其它用戶可以看到日志記錄。 但他不能創建偽記錄，而且他也不能對現有記錄進行修改或刪除。 在這種情況下，不能通過使規劃器改變操作的順序來推翻規則， 因為唯一引用`shoelace_log`的規則是一個未修飾的`INSERT`。 在更復雜的情形中這可能不是真的。 當必須為視圖提供行級別的安全性時，`security_barrier` 屬性應該應用于視圖。這樣就阻止了在行上調用惡意的選擇函數和操作，直到視圖完成了它的工作。 例如，如果上面顯示的視圖像這樣創建，它將是安全的： ``` CREATE VIEW phone_number WITH (security_barrier) AS SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%'; ``` 帶有`security_barrier`創建視圖可能執行起來更糟糕。 通常，這是沒有辦法避免的：如果可能危及安全，那么最快可能的計劃必須拒絕。 因為這個原因，缺省不啟用這個選項。 當處理的函數沒有副作用時，查詢計劃器有更大的靈活性。這樣的函數被稱為`LEAKPROOF`， 包括許多簡單、常用的操作符，例如許多相等操作符。查詢計劃器可以安全的允許這樣的函數在查詢執行過程的任何時候評估。 因為在行上不可見的調用它們不會給用戶泄露任何關于不可見行的信息。相反的， 一個函數可能會拋出一個錯誤，取決于作為參數（例如在溢出或除以零的情況下拋出一個錯誤） 接收到的值是非防止泄露的，并且如果在安全視圖的行過濾器之前應用可能提供重要的關于不可見行的信息。 理解這個是重要的，即使視圖創建時帶有了`security_barrier`選項， 狹義來講，為了安全，只有不可見元組的內容不會被傳送到可能不安全的函數。 用戶很可能對于推斷不可見的數據有其他的意思；例如，他們使用`EXPLAIN` 看到查詢計劃，或測量查詢在視圖上的運行時間。惡意攻擊者也許能夠推斷不可見數據的數量， 或者甚至獲得一些關于數據分布或常見值的信息（因為這些事情可能影響計劃的運行時間； 甚至，因為他們也反映在優化器的統計數據中，計劃的選擇）。如果關心了這些"covert channel" 類型的攻擊，那么給這些數據授予任何權限可能是不明智的。