Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-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

pgsql-hackers by date

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

pgsql-committers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group