Joshua Brindle wrote: > 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.
Yea, it would take some work but it is an idea. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
