规则和权限

由于 Postgres 规则系统对查询的重写，非初始查询指定的其他表/视图被访问．使用更新规则，这可能包括对表的写权限．

重写规则并不拥有一个独立的所有者．关系（表或视图）的所有者自动成为重写规则的缺省所有者．Postgres 规则系统改变缺省的访问控制系统的特性．因规则而使用的关系在（规则）重写时要对定义规则的关系所有者的权限进行检查．这意味着一个用户只需要对他的查询里指定的表/视图拥有所需的权限就可进行操作．

例如：某用户有一个电话号码列表，其中一些是私人的，另外的一些是办公室秘书需要的．他可以用下面方法构建（查询）：

    CREATE TABLE phone_data (person text, phone text, private bool);
    CREATE VIEW phone_number AS
        SELECT person, phone FROM phone_data WHERE NOT private;
    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 视图后，他还可以 REVOKE （撤回）他的访问权限．这样，所有对秘书视图的访问马上就失效了．

有些人会认为这种逐条规则的检查是一个安全漏洞，但事实上不是．如果这样做不能奏效，秘书将必须建立一个与 phone_number 有相同字段的表并且每天一次的拷贝数据进去．那么这是他自己的数据因而他可以赋予他允许的任何人访问的权力．一个 GRANT 意味着 "我信任你"．如果某个你信任的人做了上面的事情，那你就该想想是否该 REVOKE 了．

这个机制同样可以用于更新规则．在上一章的例子里，Al 的数据库里的表的所有者可以把（赋予）鞋带视图 GRANT SELECT，INSERT，UPDATE 和 DELETE 给 al．但对 shoelace_log 只有SELECT 权限．写日志记录的规则动作（action）仍然可以成功的执行．并且 Al 可以看到日志记录．但他不能创建伪记录，而且他也不能对现有记录进行修改或删除．