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