On 11/08/2015 11:17 PM, Craig Ringer wrote: > On 9 November 2015 at 12:40, Adam Brightwell > <adam.brightw...@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.
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
signature.asc
Description: OpenPGP digital signature
