Re: bootstrap pg_shseclabel in relcache initialization

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bootstrap pg_shseclabel in relcache initialization
Date: 2015-11-10 08:10:32
Message-ID: 9A28C8860F777E439AA12E8AEA7694F80116DF41@BPXM15GP.gisp.nec.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Joe Conway
> Sent: Tuesday, November 10, 2015 3:08 AM
> To: Craig Ringer; Adam Brightwell
> Cc: PostgreSQL Hackers
> Subject: Re: [HACKERS] 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.
>
The sepgsql does not support and its security model intends to assign
client's privileges orthogonal to database role, thus, it didn't touch
pg_shseclabel at that time. However, we can easily expect another label
provider that references database role.

> +1 for adding to the next commitfest.
>
Me also.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Artur Zakirov 2015-11-10 10:23:47 Re: [PROPOSAL] Improvements of Hunspell dictionaries support
Previous Message Amit Langote 2015-11-10 08:02:12 Re: [PROPOSAL] VACUUM Progress Checker.