Re: bootstrap pg_shseclabel in relcache initialization

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: bootstrap pg_shseclabel in relcache initialization
Дата
Msg-id CAMsr+YG1v-xA0pc-KtEYg2gm_DSBBFRpLnRYJwM_RGp5tf+giw@mail.gmail.com
обсуждение исходный текст
Ответ на bootstrap pg_shseclabel in relcache initialization  (Adam Brightwell <adam.brightwell@crunchydata.com>)
Ответы Re: bootstrap pg_shseclabel in relcache initialization
Список pgsql-hackers
On 9 November 2015 at 12:40, Adam Brightwell
<adam.brightwell@crunchydata.com> wrote:
> Hi All,
>
> While working on an auth hook, I found that I was unable to access the
> pg_shseclabel system table while processing the hook.  I discovered
> that the only tables that were bootstrapped and made available at this
> stage of the the auth process were pg_database, pg_authid and
> pg_auth_members.  Unfortunately, this is problematic if you have
> security labels that are associated with a role which are needed to
> determine auth decisions/actions.
>
> Given that the shared relations currently exposed can also have
> security labels that can be used for auth purposes, I believe it makes
> sense to make those available as well.  I have attached a patch that
> adds this functionality for review/discussion.  If this functionality
> makes sense I'll add it to the commitfest.

Your reasoning certainly makes sense to me. I'm a little surprised
this didn't cause issues for SEPostgreSQL already.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Patch: Implement failover on libpq connect level.
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Adjust errorcode in background worker code