Bruce Momjian wrote:
Tom Lane wrote:
Gregory Stark <st...@enterprisedb.com> writes:
I don't think partitioning is really the same thing as row-level
security.
Of course not, but it seems to me that it can be used to accomplish most
of the same practical use-cases. The main gripe about doing it via
partitioning is that the user's nose gets rubbed in the fact that there
can't be an enormous number of different security classifications in the
same table (since he has to explicitly make a partition for each one).
But the proposed implementation of row-level security would poop out
pretty darn quick for such a case, too, and frankly I'm not seeing an
application that would demand it.
OK, putting on my crazy idea hat, if we split the primary and foreign
keys by partition, it would give us polyinstantiation:
http://en.wikipedia.org/wiki/Polyinstantiation
because our unique indexes do not apply across partitions.
Polyinstantiation is a desirable security feature and one that would be
tough to implement without partitions.
Polyinstantiation in this manner won't do it I don't think (if I'm understanding
you correctly). As KaiGai already said, SELinux policy is flexible so we'll have
more than just BLP policy to worry about.
Also a top secret user will need to see all rows when he selects, and they
should still have unique keys. He won't be able to write to secret or unclass
rows but he'll be able to see them.
Further, a secret user may be able to see top secret rows, but not some of the
columns, going back to my coordinates example. He'd have to use a trusted stored
procedure that can do the necessary operations to fuzz the data.
A flexible policy is really the crux of this. We aren't trying to reproduce what
other DBMS's have done, we are trying to integrate with a completely flexible
policy from the ground up.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
