Postgresql 中文操作指南

41.5. Rules and Privileges #

由于 PostgreSQL 规则系统重写了查询，所以会访问到原始查询中没有使用的其他表/视图。当使用更新规则时，这可能会包括对表的写访问权限。

Due to rewriting of queries by the PostgreSQL rule system, other tables/views than those used in the original query get accessed. When update rules are used, this can include write access to tables.

重写规则没有单独的所有者。关系（表或视图）的所有者自动成为为其定义的重写规则的所有者。PostgreSQL 规则系统改变了默认访问控制系统的行为。除了与安全调用者视图关联的 SELECT 规则之外（请参阅 CREATE VIEW ），由于规则而使用的所有关系都将针对规则所有者的权限进行检查，而不是调用规则的用户。这意味着，除了安全调用者视图之外，用户只需要对查询中明确命名的表/视图拥有所需权限。

Rewrite rules don’t have a separate owner. The owner of a relation (table or view) is automatically the owner of the rewrite rules that are defined for it. The PostgreSQL rule system changes the behavior of the default access control system. With the exception of SELECT rules associated with security invoker views (see CREATE VIEW), all relations that are used due to rules get checked against the privileges of the rule owner, not the user invoking the rule. This means that, except for security invoker views, users only need the required privileges for the tables/views that are explicitly named in their queries.

例如：用户有一份电话号码列表，其中一些是私有的，其他则是办公室助理感兴趣的。用户可以构建以下内容：

For example: A user has a list of phone numbers where some of them are private, the others are of interest for the assistant of the office. The user can construct the following:

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 assistant;

除了该用户（和数据库超级用户）以外，任何人不能访问 phone_data 表。但是由于 GRANT，该助理可以在 phone_number 视图上运行 SELECT。规则系统将重写 phone_number 中的 SELECT 为 phone_data 中的 SELECT。由于用户是 phone_number 的所有者，因此也是该规则的所有者，所以现在根据用户权限检查对 phone_data 的读取访问，并且允许该查询。还会执行访问 phone_number 的检查，但这是针对调用用户进行的，所以除了用户和助理之外，没有人可以使用它。

Nobody except that user (and the database superusers) can access the phone_data table. But because of the GRANT, the assistant can run a SELECT on the phone_number view. The rule system will rewrite the SELECT from phone_number into a SELECT from phone_data. Since the user is the owner of phone_number and therefore the owner of the rule, the read access to phone_data is now checked against the user’s privileges and the query is permitted. The check for accessing phone_number is also performed, but this is done against the invoking user, so nobody but the user and the assistant can use it.

每条规则都会对其权限进行检查。因此目前只有助理可以看到公开电话号码。但是该助理可以设置另一个视图并将其访问权限授予公众。这样，任何人都可以通过该助理的视图查看 phone_number 数据。该助理无法做的是创建一个直接访问 phone_data 的视图。（实际上该助理可以，但它不起作用，因为在权限检查中会拒绝每次访问。）而且，只要该用户注意到该助理打开了其 phone_number 视图，用户就可以撤销该助理的访问权限。该助理的视图的任何访问都会立即失败。

The privileges are checked rule by rule. So the assistant is for now the only one who can see the public phone numbers. But the assistant can set up another view and grant access to that to the public. Then, anyone can see the phone_number data through the assistant’s view. What the assistant cannot do is to create a view that directly accesses phone_data. (Actually the assistant can, but it will not work since every access will be denied during the permission checks.) And as soon as the user notices that the assistant opened their phone_number view, the user can revoke the assistant’s access. Immediately, any access to the assistant’s view would fail.

人们可能认为按规则检查是一个安全漏洞，但实际上并非如此。但是，如果不以这种方式运行，该助理可以设置一个与 phone_number_具有相同列的表，然后每天将数据复制到那里。那么这将是该助理自己的数据，该助理可以向他们想要的任何人授予访问权限。_GRANT 命令意味着“我相信你”。如果你信任的人做了以上事情，那么是时候考虑一下，然后使用 REVOKE。

One might think that this rule-by-rule checking is a security hole, but in fact it isn’t. But if it did not work this way, the assistant could set up a table with the same columns as phone_number and copy the data to there once per day. Then it’s the assistant’s own data and the assistant can grant access to everyone they want. A GRANT command means, “I trust you”. If someone you trust does the thing above, it’s time to think it over and then use REVOKE.

请注意，虽然可以使用视图使用上述技术来隐藏某些列的内容，但除非已设置 security_barrier 标志，否则无法可靠地隐藏看不见的行中的数据。例如，以下视图是不安全的：

Note that while views can be used to hide the contents of certain columns using the technique shown above, they cannot be used to reliably conceal the data in unseen rows unless the security_barrier flag has been set. For example, the following view is insecure:

CREATE VIEW phone_number AS
    SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';

此视图可能看起来是安全的，因为规则系统会将 phone_number 中的任何 SELECT 重写为 phone_data 中的 SELECT，并添加仅需要 phone 不以 412 开头的条目的限定。但是，如果用户可以创建自己的函数，那么说服计划程序在 NOT LIKE 表达式之前执行用户定义的函数并不困难。例如：

This view might seem secure, since the rule system will rewrite any SELECT from phone_number into a SELECT from phone_data and add the qualification that only entries where phone does not begin with 412 are wanted. But if the user can create their own functions, it is not difficult to convince the planner to execute the user-defined function prior to the NOT LIKE expression. For example:

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 函数。即使阻止用户定义新函数，内置函数也可用于类似的攻击。（例如，大多数转换函数在其产生的错误消息中包含其输入值。）

Every person and phone number in the phone_data table will be printed as a NOTICE, because the planner will choose to execute the inexpensive tricky function before the more expensive NOT LIKE. Even if the user is prevented from defining new functions, built-in functions can be used in similar attacks. (For example, most casting functions include their input values in the error messages they produce.)

类似的考虑适用于更新规则。在前一节的示例中，示例数据库中表的所有者可以将 SELECT、INSERT、UPDATE 和 DELETE 权限授予 shoelace 视图上的其他人，但只能对 shoelace_log 授予 SELECT。写日志条目的规则动作仍将成功执行，并且该其他用户可以看到日志条目。但是，他们不能创建伪造条目，也不能操纵或删除现有条目。在这种情况下，不可能通过说服计划程序改变操作顺序来破坏规则，因为唯一引用 shoelace_log 的规则是未限定的 INSERT。在更复杂的方案中可能并非如此。

Similar considerations apply to update rules. In the examples of the previous section, the owner of the tables in the example database could grant the privileges SELECT, INSERT, UPDATE, and DELETE on the shoelace view to someone else, but only SELECT on shoelace_log. The rule action to write log entries will still be executed successfully, and that other user could see the log entries. But they could not create fake entries, nor could they manipulate or remove existing ones. In this case, there is no possibility of subverting the rules by convincing the planner to alter the order of operations, because the only rule which references shoelace_log is an unqualified INSERT. This might not be true in more complex scenarios.

当视图需要提供行级安全性时，应将 security_barrier 属性应用于视图。这可防止恶意选取的函数和运算符在视图完成工作之前从行接收值。例如，如果上面的视图已创建如下所示，则它将是安全的：

When it is necessary for a view to provide row-level security, the security_barrier attribute should be applied to the view. This prevents maliciously-chosen functions and operators from being passed values from rows until after the view has done its work. For example, if the view shown above had been created like this, it would be secure:

CREATE VIEW phone_number WITH (security_barrier) AS
    SELECT person, phone FROM phone_data WHERE phone NOT LIKE '412%';

使用 security_barrier 创建的视图的性能可能远低于不使用此选项创建的视图。通常，没有办法避免这种情况：如果可能损害安全性，则必须拒绝最快的计划。因此，默认情况下不启用此选项。

Views created with the security_barrier may perform far worse than views created without this option. In general, there is no way to avoid this: the fastest possible plan must be rejected if it may compromise security. For this reason, this option is not enabled by default.

当处理没有副作用的函数时，查询计划程序具有更大的灵活性。此类函数称为 LEAKPROOF，包括许多简单、常用的运算符，如许多相等运算符。查询计划程序可以安全地允许在查询执行过程中的任何时候计算此类函数，因为在用户不可见的行上调用它们不会泄露有关不可见行任何信息。此外，如果函数不使用自变量或不会从安全屏障视图接收任何自变量，则不必将其标记为 LEAKPROOF 以进行下推，因为它们从未从视图中接收数据。相反，根据收到的自变量值可能抛出错误的函数（比如在溢出或除以零时抛出错误的函数）是不可泄露的，并且如果在安全视图的行过滤器之前应用，则可能会提供有关不可见行的重要信息。

The query planner has more flexibility when dealing with functions that have no side effects. Such functions are referred to as LEAKPROOF, and include many simple, commonly used operators, such as many equality operators. The query planner can safely allow such functions to be evaluated at any point in the query execution process, since invoking them on rows invisible to the user will not leak any information about the unseen rows. Further, functions which do not take arguments or which are not passed any arguments from the security barrier view do not have to be marked as LEAKPROOF to be pushed down, as they never receive data from the view. In contrast, a function that might throw an error depending on the values received as arguments (such as one that throws an error in the event of overflow or division by zero) is not leak-proof, and could provide significant information about the unseen rows if applied before the security view’s row filters.

了解这一点很重要，即使使用 security_barrier 选项创建的视图也旨在仅在有限的意义上是安全的，即不会将不可见元组的内容传递给可能不安全的函数。用户可能还有其他方法可以对看不见的数据进行推断；例如，他们可以使用 EXPLAIN 看到查询计划，或测量针对该视图的查询的运行时间。恶意攻击者可能会推断出一些关于不可见数据量的信息，甚至获得有关数据分布或最常见值的一些信息（因为这些事情可能会影响计划的运行时间；甚至因为它们也反映在优化程序统计信息中，所以计划的选择）。如果这些类型的“隐蔽信道”攻击令人担忧，那么最好不要授予对数据的任何访问权限。

It is important to understand that even a view created with the security_barrier option is intended to be secure only in the limited sense that the contents of the invisible tuples will not be passed to possibly-insecure functions. The user may well have other means of making inferences about the unseen data; for example, they can see the query plan using EXPLAIN, or measure the run time of queries against the view. A malicious attacker might be able to infer something about the amount of unseen data, or even gain some information about the data distribution or most common values (since these things may affect the run time of the plan; or even, since they are also reflected in the optimizer statistics, the choice of plan). If these types of "covert channel" attacks are of concern, it is probably unwise to grant any access to the data at all.