Re: How to get SE-PostgreSQL acceptable

On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hmm. If that's the expected application environment then the patch as
> proposed has fatal performance problems anyway, for lack of a way to
> get rid of no-longer-referenced pg_security rows. We had been led to
> understand that there wouldn't be all that many distinct labels in use,
> but this seems to imply that there are going to be $bignum of them.
> That changes pg_security leakage from a can-live-with-for-first-cut
> issue to a must-fix-to-be-credible issue.

It's worth noting that this is yet another thing that is mostly a
problem in the context of row-level security. It seems to me that if
security labels are only applied to tables and columns, then it will
be possible to scan the whole database relatively quickly and find all
the labels that are still in use, probably without breaking a sweat.
On the other hand, when you have row-level security, it gets a lot
harder.

I'm wondering if this problem could be solved with a sort of
mark-and-sweep garbage collection: add a boolean column `used' to
pg_security (which I really think out to be renamed to
pg_selinux_context or something, and make a new table if we someday
support Trusted Solaris or whatever). Whenever you do an OID lookup
and find a row that says "false", do a non-transactional update and
change it to say "true".

Then you can write something which goes through and sets all the rows
to false and then visits every row of every table in the database and
forces OID lookups on the security ID of each. When you get done, any
rows that still say false are unreferenced and can be killed.

Also... even if there are thousands of contexts, it only matters to
the extent that there is a lot of churn, and I'm not sure whether
that's something that is expected. Josh Brindle, any thoughts?

> (Just for context, thousands of partitions isn't practical with our
> current implementation, but might be in the future.)
>
>> Nonetheless, this conversation seems moot now that Tom has walled off
>> and won't even discuss row-level access controls.
>
> You realize, I trust, that I don't have the only vote around here.
> But I am convinced that the row-level-security aspect of this proposal
> is far less than fully baked, and isn't going to become so in the time
> frame available for 8.4.

You have a pretty big vote, though. But, I see signs though that you
might relent at some future point when and if the proposal is
well-baked. In any case, whether or not we do row-level security at
some point in the future, you've certainly convinced me that the
issues have not been thought through in enough detail to consider
including any of this in 8.4.

...Robert