Tom Lane wrote:
Joshua Brindle <met...@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
It's one application environment, maybe not a common one but one I've seen.
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.
I see. SELinux handles this by dynamically filling a sidtab (context to security
identifier table) at runtime. This can be done because the contexts are stored
as strings in the xattr's. I understand KaiGai wanted to save space in the
tables so he stored sids, which would require a persistent sid mapping.
I'm not sure this is a deal breaker though, I still know people that would
rather have it now that may have performance issues than wait for something that
can prune the sid mappings.
(Just for context, thousands of partitions isn't practical with our
current implementation, but might be in the future.)
There are still other unresolved issues with partitions that I pointed out
upthread.
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.
I know, but I also know how opensource communities work :) I haven't seen any
enthusiastic support from other commiters which means, at least for the time
being, it's being tabled.
I mean no disrespect, I also agree with your assessment about the maintenance
burden. As an opensource developer myself I would be nervous about intrusive
patches that I don't understand, and what that means for me when I write new
patches.
This brings up my next point. The purpose of pgace is to mitigate this issue.
The core team only needs to know when/where/why data can be selected, updated,
deleted, etc and maintain the pgace hooks. As long as your side of the boundary
stays correct the security model shouldn't break. Granted if you add new things
(a new loadable module system, new kinds of large objects, etc) those would need
to have the hooks added from the get go.
This is similar to how the Linux kernel works, and the Xorg's XACE works. We do
watch for updates and sometimes people mess things up but it isn't hard to spot.
Especially with a small core team like postgres I'd think you guys could
successfully spot places access controls need to be added.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
