为什么没有为 Postgres 视图启用行级安全? [英] Why isn't row level security enabled for Postgres views?
问题描述
我需要严格控制 Postgres 数据的读取和写入.可更新视图一直提供非常好的、严格的、对我的数据读取的控制，并允许我添加有价值的计算列.Postgres 9.5 行级安全性引入了一种新的、强大的方法来控制我的数据.但是我不能同时使用这两种技术视图和行级安全性.为什么?
主要是因为无法追溯更改视图的工作方式.我希望能够为视图支持 SECURITY INVOKER(或等效的)，但据我所知目前不存在这样的功能.
您可以正常使用行安全性过滤对视图本身的访问.
视图访问的表也将应用其行安全规则.但是，他们会看到 current_user 为视图创建者，因为视图访问表(和其他视图)具有创建/拥有视图的用户的权限.>
如果您愿意介入并帮助开发您需要的功能，也许值得在 pgsql-hackers 或 pgsql-general 上提出这个问题?
也就是说，虽然将访问表视为创建用户并相应地更改 current_user，但它们不会阻止您使用自定义 GUC、session_user 或其他上下文行安全策略中的信息.您可以对视图使用行安全性，只是不要(有用)基于 current_user 进行过滤.
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?
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.
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.
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?
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屋！
