为什么未为Postgres视图启用行级安全性？ [英] Why isn't row level security enabled for Postgres views?

问题描述

我需要严格控制Postgres数据的读写。可更新的视图始终能够很好，严格地控制我的数据读取，并允许我添加有价值的计算列。在Postgres 9.5中，行级安全性引入了一种新的强大方法来控制我的数据。但是我不能同时使用两种技术视图和行级安全性。为什么？

I need strict control of the reading and writing of my Postgres data. Updatable views have always provided very good, strict, control of the reading of my data and allows me to add valuable computed columns. With Postgres 9.5 row level security has introduced a new and powerful way to control my data. But I can't use both technologies views, and row level security together. Why?

推荐答案

基本上是因为无法追溯更改视图的工作方式。我希望能够支持 SECURITY INVOKER （或等效功能）的视图，但据我所知，目前尚不存在这样的功能。

Basically because it wasn't possible to retroactively change how views work. I'd like to be able to support SECURITY INVOKER (or equivalent) for views but as far as I know no such feature presently exists.

您可以使用行安全性正常过滤对该视图自身的访问。

You can filter access to the view its self with row security normally.

该视图访问的表也将应用其行安全性规则。但是，他们会将 current_user 视为视图创建者，因为视图访问表（和其他视图）具有创建/删除用户的权利拥有视图。

The tables accessed by the view will also have their row security rules applied. However, they'll see the current_user as the view creator because views access tables (and other views) with the rights of the user who created/owns the view.

如果您愿意介入并帮助开发所需的功能，也许值得在pgsql-hackers上提出这个建议，或者

Maybe it'd be worth raising this on pgsql-hackers if you're willing to step in and help with development of the feature you need, or pgsql-general otherwise?

也就是说，虽然以创建用户的身份查看访问表并相应地更改 current_user ，不要阻止您在行安全策略中使用自定义GUC， session_user 或其他上下文信息。您可以将行安全性与视图一起使用，只是不能（有用）根据 current_user 进行过滤。

That said, while views access tables as the creating user and change current_user accordingly, they don't prevent you from using custom GUCs, the session_user, or other contextual information in row security policies. You can use row security with views, just not (usefully) to filter based on current_user.

这篇关于为什么未为Postgres视图启用行级安全性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！