Re: bootstrap pg_shseclabel in relcache initialization

On 11/08/2015 11:17 PM, Craig Ringer wrote:
> On 9 November 2015 at 12:40, Adam Brightwell
> <adam(dot)brightwell(at)crunchydata(dot)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.

Currently sepgsql at least does not support security labels on roles,
even though nominally postgres does. If the label provider does not
support them (as in sepgsql) you just get a "feature not supported" type
of error when trying to create the label. I'm not sure if there are any
other label providers in the wild other than sepgsql, but I should think
they would all benefit from this change.

+1 for adding to the next commitfest.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development