Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
От | Tom Lane |
---|---|
Тема | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
Дата | |
Msg-id | 2514770.1725729411@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
|
Список | pgsql-bugs |
Basha <Basha@maxcontact.com> writes: > As suggested, tried creating the below RLS policy on the pg_database table. But seems it does not check for the connectpermission. [ pokes around... ] Ah indeed, because check_enable_rls has a hard-wired assumption that no built-in table has any RLS: /* Nothing to do for built-in relations */ if (relid < (Oid) FirstNormalObjectId) return RLS_NONE; I wonder if we should remove that? It's only saving one syscache lookup (and if we were hot about that, most of the callers have an open Relation that could be passed). I did check that this policy works as-expected if that test is deleted. Still, making such a change would amount to actively supporting RLS on catalogs, rather than just a laissez-faire "you can use it if it works" approach. I'm not convinced we want to go there, because for a lot of the catalogs there are going to be additional access pathways such as I mentioned for roles. I do not want to buy into those things becoming arguable security bugs. And I *definitely* don't want to try to close off system accesses to catalogs based on RLS. regards, tom lane
В списке pgsql-bugs по дате отправления: