From: KaiGai Kohei on
(2010/07/10 2:12), Simon Riggs wrote:
> On Fri, 2010-07-09 at 11:09 -0400, Stephen Frost wrote:
>>> 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.
>>
>> I don't see how you could remove ExecCheckRTPerms..? It's what
>> handles
>> all permissions checking for DML (like, making sure you have SELECT
>> rights on the table you're trying to query). I could see forcing plan
>> invalidation when permissions are updated, sure, but that doesn't mean
>> you can stop doing them altogether anywhere. Where would you move the
>> permissions checking to?
>
> I apologise, when I said removing the check altogether, I meant removing
> from the executor path.
>
The Linux kernel has a facility that notify userspace applications when
the security policy is changed. This message is delivered using netlink
socket from the kernel. Once we received it, then SE-PG's access control
decision cache will be invalidated. Even if it was invalidated in mid-query,
please note that the older policy was valid when we make access control
decision.

If and when we have cached plans being already permission checked,
I'd like the core PG to ask external securities whether it is still
valid from the perspective of external security policy. If already
invalid, we can check permissions again on the cached plan.

Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers