【问题标题】:Possible to restrict PostgreSQL security definer function to RLS use?可以将 PostgreSQL 安全定义器函数限制为 RLS 使用吗?
【发布时间】:2021-11-14 14:35:36
【问题描述】:

我将 RLS(行级安全性)与 supbase.io 一起用于“无服务器”应用程序。我必须为 RLS 策略使用各种安全定义器功能。这些仍然可以通过 supabase 的 rpc 库调用。是否有限制调用这些函数只能由管理员(我)或作为 RLS 策略的一部分使用?

例如:

CREATE OR REPLACE FUNCTION get_bases_editable_or_viewable_for_user(user_id uuid, allow_edit bool)
returns setof bigint as $$
  select base_id
  from access_controls
  where access_controls.user_id = $1 AND ($2 AND access_controls.access_level = 'editor') OR access_controls.access_level = 'viewer';
$$ stable language sql security definer;

CREATE policy "Users can read bases they are editors or viewers of"
on public.bases
for select using ( bases.id in (get_bases_editable_or_viewable_for_user(auth.uid(), true)) );

get_bases_editable_or_viewable_for_user 允许任何用户在拥有另一个用户的 UID 后,找出该用户作为编辑者或查看者可以访问的 UID:

supabase.rpc(
  "get_bases_editable_or_viewable_for_user",
  { user_id: "dddddde6-1111-4bdf-aaaa-33336ccc31ee", allow_edit: true }
)
.then(console.log) // => bad

最大限度地减少信息泄露的机会对于最大限度地提高应用程序的安全性和用户的隐私至关重要。

【问题讨论】:

  • 与其在此重复,请查看CREATE POLICYNotes 部分。简短版本的策略以运行查询的用户的权限运行。因此,如果管理员以外的用户要运行查询,则不能过多地限制访问。
  • 策略定义的USING 子句必须返回boolean。这样的函数不会泄露它不应该泄露的信息。
  • @LaurenzAlbe 抱歉,我有一些如何设法粘贴一些损坏的代码。我现在已经修好了。我看不出如何将bases.id 移动到函数中。

标签: postgresql row-level-security supabase


【解决方案1】:

您不能以这种方式限制函数的权限,因为运行查询的用户必须能够执行它。

我看到了两种改进方法:

  • 从函数中省略第一个参数,以便它只为当前用户提供结果。然后没有人可以看到其他用户的信息。

  • 除上述之外,您还可以将bases.id 作为函数参数传递,并让函数返回boolean。这样你就无法得到一个列表,但性能可能会受到影响,因为必须为每一行调用该函数。

【讨论】:

  • 我刚刚尝试了您的第一个建议,这似乎有效。非常感谢。 supabase相关问答:github.com/supabase/supabase/discussions/…
  • 抱歉,如果这是噪音,因为我不能 100% 确定这些信息对一般 PostgreSQL 用户有多大用处,但是当在 Supbase.io 上使用 RPC 时,您可以创建一个私有模式,在那里定义函数并从公共 RLS 政策中使用它们:github.com/supabase/supabase/discussions/…
  • 您可以调用该函数,即使它位于不同的架构中。也许您的 API 使这成为不可能,但总的来说这无济于事。
猜你喜欢
  • 1970-01-01
  • 2021-05-19
  • 1970-01-01
  • 2011-09-16
  • 2020-05-05
  • 1970-01-01
  • 2018-06-22
  • 2020-08-14
  • 2016-07-13
相关资源
最近更新 更多