On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs <simon@2ndquadrant.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.
> 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).
> Strangely, I was looking into removing the ExecCheckRTPerms check
> altogether by forcing plan invalidation when permissions are updated.
> That would be a performance tweak that would render this change useless.
Huh. Obviously, I would have refrained from committing the patch had
I known that it was going to conflict with work someone else was doing
in this area, at least until we reached consensus on which way to go
with it, but since you didn't post about it on -hackers, I had no idea
that was the case. Sounds like you should probably post your proposal
and we can discuss what to do in general and also with respect to this
hook.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company