pg_dump needs SELECT privileges on irrelevant extension table
От | Jacob Champion |
---|---|
Тема | pg_dump needs SELECT privileges on irrelevant extension table |
Дата | |
Msg-id | 00d46a48-3324-d9a0-49bf-e7f0f11d1038@timescale.com обсуждение исходный текст |
Ответы |
Re: pg_dump needs SELECT privileges on irrelevant extension table
|
Список | pgsql-bugs |
Hi all, We have a situation where we need to revoke SELECT on a table that belongs to our extension, and we also need to let less privileged users dump the extension's external config tables. (The restricted table's contents are exposed through a security_barrier view, and it's a cloud environment where "admin" users don't necessarily have true superuser access.) Since the restricted table is internal, its contents aren't included in dumps anyway, so we expected to be able to meet both use cases at once. Unfortunately: $ pg_dump -U unprivileged_user -d postgres pg_dump: error: query failed: ERROR: permission denied for relation ext_table pg_dump: error: query was: LOCK TABLE public.ext_table IN ACCESS SHARE MODE ...and there appears to be no way to work around this with --exclude-table, since the table is part of the extension. It looks like the only reason pg_dump locks this particular table is because it's been marked with DUMP_COMPONENT_POLICY, which needs a lock to ensure the consistency of later pg_get_expr() calls. That stings for two reasons: 1) it doesn't seem like you need SELECT access on a table to see its policies, and 2) we have no policies on the table anyway; there are no pg_get_expr() calls to protect. So I've attached the simplest backportable workaround I could think of: unmark DUMP_COMPONENT_POLICY for a table that has no policies at the time of the getTables() query. This is similar to the ACL optimization that back branches do; it should ensure that there will be no pg_get_expr() calls on pg_policy for that table later, due to repeatable-read, and it omits the lock when there's no reason to grab it. It won't fix the problem for tables that have do policies, but I don't have any ideas for how to do that safely, unless there's some lock mode that uses fewer privileges. I also attached a speculative backport to 11 to illustrate what that might look like, but first I have to convince you it's a bug. :) WDYT? Thanks, --Jacob
Вложения
В списке pgsql-bugs по дате отправления: