Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Date: 2010-07-09 17:07:52
Message-ID: 1278695272.29736.700.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, 2010-07-09 at 11:07 -0400, Robert Haas wrote:
> On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs <simon(at)2ndquadrant(dot)com>
> wrote:
> > The loadable module doesn't "gain control" here it simplify kicks-in
> > after, and in addition to, normal checking. That just means you have
> the
> > option of failing for additional reasons.
>
> True. We could change it so that the normal checking is bypassed if
> the hook is installed, and leave it up to the hook whether to call the
> standard checks as well, but I don't think there's much of a use case
> for that.

With respect, there doesn't seem to be much use case anyway. I'm sorry
to be expressing that opinion now; been away for a while. I am somewhat
amazed that Tom isn't dancing on your head for proposing it though.

> > We're not passing in any form of context other than the rangetable
> so
> > what additional reasons could there be? This is of no use to
> anything
> > that uses object labelling. We're not even at the part of the
> executor
> > where we would be able to identify objects yet, so I can't see what
> > value this brings. Though I am certainly in favour in general terms
> of
> > simple changes to enhance security configuration features.
>
> Well, KaiGai Kohei already posted a proof-of-concept patch showing how
> this could be used by a simple SE-PostgreSQL implementation. Since we
> don't have a security labelling facility yet, he used the comment on
> the relation to store the security label (there are other ways it
> could be done too, of course).

What's the difference between that and a GRANT command? GRANT is
designed to allow privileges to be defined at table level. I don't see
how a plugin whose only API input is a rangetable and which executes
before any tuples have been touched can possibly add value here.

KaiGai's had an uphill task here and I don't wish to be part of slowing
him down. I'm not seeing how this moves label security forwards in any
measurable way.

Tom's test of a useful plugin has been one where a useful contrib module
gets added at the same time. I don't think a useful plugin has been
demonstrated or produced, as yet.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Simon Riggs 2010-07-09 17:12:12 Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Previous Message Simon Riggs 2010-07-09 16:51:48 Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-07-09 17:12:12 Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Previous Message Robert Haas 2010-07-09 17:04:13 Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock