Joshua Brindle <method@manicmethod.com> writes:
> In reality it isn't, unless postgres won't mind thousands of
> partitions being made. In the military/gov implementations BLP lets
> you have hierarchical levels and non-hierarchical categories. Since I
> linked to an article about it upthread I assumed everyone
> participating was familiar but perhaps not. Typically there are 3
> levels, unclass, secret, top secret. In addition to those 3 levels
> there may be a few, hundreds or even thousands of categories. Those
> categories apply to each of the levels so if you are using 1000
> categories you have 3*1000 possible BLP labels. On top of that SELinux
> has users, roles and types, which are all also multiplied.
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.
(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.
regards, tom lane
