Re: How to get SE-PostgreSQL acceptable

Andrew Sullivan <ajs(at)crankycanuck(dot)ca> writes:
> On Wed, Jan 28, 2009 at 01:49:21PM -0500, Joshua Brindle wrote:
>> The costs are nil for people who don't want this feature.

> That's also false, because developers who don't care about the feature
> have to continue to maintain it as part of the system. If maintenance
> were free, I suspect nobody would be objecting to the feature. But
> this feature will in fact constrain future development and will impose
> maintenance requirements on the programmers of the system.

Right. The major implementation problem I have with row-level security
is that it will require sticking its hands into every part of the
backend; at least if you want it to be actually *secure* with no holes,
and if not I guess I'm failing to grasp the point. Every future patch
will have to be vetted to ensure that it's not accidentally breaking
that security. This stems directly from the fact that you're trying to
impose behavior that's fundamentally at odds with SQL, and therefore
there isn't any well-defined choke point at which you could apply the
checks and be done with it. The system simply isn't modularized that
way. (Of course we could throw it all away and start over...)

BTW, in regard to the upthread question about how much of the patch
could be discarded if we removed row-level security: having now taken
another look through it, I'd put the fraction at well north of 90%.
(That's exclusive of the security policy file, which I don't understand
at all and so can't tell how much might be specific to row security.)
What's worse, the current patch footprint is conservative because the
placement of hooks is simply wrong. You can't usefully apply checks in
simple_heap_insert, for example, since it has no idea who called it or
why. It's got to be done at a higher level and therefore in a lot more
places. And I don't see any attempt at all to restrict system-driven
fetches, yet surely there has to be some control over that (otherwise
why are we worrying about system-driven updates?)

regards, tom lane