Re: How to get SE-PostgreSQL acceptable - Mailing list pgsql-hackers

On Wed, Jan 28, 2009 at 3:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Sullivan <ajs@crankycanuck.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?)

I'm not clear that I understand why it would be necessary for
row-level security to touch every part of the code.  If the current
implementation requires that, then maybe that's a defect in the
implementation rather than an inherent problem with row-level
security.  It seems to me that the crucial decision is "Where are we
trying to erect the security wall?".  If we're trying to put it
between the client and the postgres backend, then maybe the right
thing to do is apply some sort of processing step to each query that
is submitted, essentially rewriting "SELECT * FROM a, b" as "SELECT *
FROM a, b WHERE you_can_see(a.securityid) AND
you_can_see(b.securityid)".  Maybe you (Tom) still won't like this
because it breaks SQL semantics, but it seems like it would at least
centralize the code.  Unless I'm totally off base here?

...Robert