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 по дате отправления: