Joshua Brindle wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Gregory Stark <stark@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
