Re: BUG #17511: Inconsistent permissions on some information_schema tables

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #17511: Inconsistent permissions on some information_schema tables
Дата
Msg-id CAKFQuwY=7GALr6LJqT3U2uhSf1p_49dc2dyQmMgkXv1s-xM+0g@mail.gmail.com
обсуждение исходный текст
Ответ на BUG #17511: Inconsistent permissions on some information_schema tables  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #17511: Inconsistent permissions on some information_schema tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Mon, Jun 6, 2022 at 11:50 AM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:

Bug reference:      17511
Logged by:          Kirk Parker
Email address:      khp@equatoria.us
PostgreSQL version: 13.7
Operating system:   AWS Linux 2 -- 4.14.276-211.499.amzn2.x86_64
Description:       
[...]
The table at issue is constraint_column_usage--the ordinary role 'apache'
does not have SELECT rights to that table, though it does to the other two
catalog tables used by this query.

Yes, there's an easy workaround by just GRANTing SELECT on that table to
'apache', but it seems like an odd inconsistency. Interestingly, the same
limitation does not apply to pg_catalog.pg_get_constraintdef(), which is
used by psql's \dt command, but that query does not produce the local column
name as a separate result column (which is more useful for my immediate
purpose here.)

Haven't tried to duplicate but I'm not following.

information_schema provides a view of the database that is filtered by user permissions.  pg_catalog does not take into consideration permissions.  This would be on the contents.  All users can select from either without getting a permission denied error.

David J.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17511: Inconsistent permissions on some information_schema tables
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error