行安全性历史

来自 PostgreSQL wiki
跳转到导航跳转至搜索

2010 年先前的讨论

先决条件

  • 在我们尝试总体进行行安全性解决之前，不管是否使用标签，我们都需要修复视图中的数据泄露问题。

问题：RLS 的泄露视图

  • 此问题可总结为：不受信任的用户可以定义一个函数，其中存储其展示的所有信息，然后查询通过该函数以使其说服计划者向该函数发送基础表中的每一行，从而泄露视图原来打算阻止泄露的表中的数据。

在 此消息 中，KaiGai 指出我们有两个导致此问题的原因，但两者都会造成相同的信息泄露。

  • [1] 在特定扫描计划中对限定符进行求值时，出现意外顺序
    • 当扫描计划有多个限定符来过滤已扫描元组时，优化器会根据其执行估计成本对限定符进行排序。如果一个外在函数的成本比来自视图定义的其他限定符的成本小，那么外在函数将比其他函数更早进行求值，然后可能向恶意用户定义的函数提供不可见元组的内容。
    • 它将在以下部分重新排序order_qual_clauses().
  • [2] 意外把限定符分布到连接循环内部
    • 当计划器制定扫描计划时，它尝试将扫描的限定符分布到尽可能小的单元中。例如，如果某个函数只需要来自某个表中的参数，它将被分布到该表的扫描计划中，而不是连接外部。
    • 当视图包含 A 和 B 之间的 JOIN 子句时，用户可以通过他自己的 WHERE 子句引用该视图。如果一个子句只需要依赖 A 的参数，那么计划器将该子句分布到 A 的扫描计划中。结果，要过滤掉的元组可能对用户定义的函数可见。
    • 它将在以下部分进行分布distribute_qual_to_rels().

讨论

  • 在 [2] 点，如果我们禁止所有外生函数下移到联接循环中，这样会导致不可忽视的性能下降，尽管该视图可能并非旨在用于安全目的。
  • 需要一种方法来提供提示，以说明该视图是否被定义用于安全目的。
    • Tom Lane 建议CREATE SECURITY VIEW AS ...语句。
    • 哪个是默认值尚未确定。安全视图？常规视图？
    • 如何通过 GUC 选项来指定默认值？否决。
  • 此外，Robert Haas 建议 测试用户权限，以了解他们是否有权限在没有 vires 的情况下引用基础表。如果可用，即使用户定义的函数在联接循环内评估，最终也是无害的。
    • 有一个人反对这条规则，因为该检查将应用于规划阶段，而非执行阶段。
  • KaiGai 提交了一个 概念验证补丁程序，可以阻止将外生函数下移到安全视图中。
  • 在 [1] 点，我们还没有任何活跃的讨论。

PG 中关于 RLS 的讨论

取自 "https://wiki.postgresql.ac.cn/index.php?title=Row_security_history&oldid=21309"