> I tried to summarize the proposed options, as follows:
>
> o : merit x : demerit X : unacceptable demerit
>
> * 1 security system column, 1 security feature (DAC or MAC)
> o It suitable for a single security system column implementation.
> x If a user want to use both of DAC and MAC concurrently, he has
> to choose one of them.
> o It allows all the security feature on the common framework,
> suitable for the original Row-level ACLs purpose.
>
> * 2 security system column, 2 security feature (DAC and MAC)
> o It allows both of DAC and MAC consurrently, without remarkable
> regressions.
> x It needs two new security system columns.
> x What is the purpose of the Row-level security in original?
>
> * 1 security system column, 2 security feature
> X It gives us catastrophic regression in user-interface, performance
> and code complexity. Its merit is trivial compared to its demerit.
Obviously sandwhiching two values in one column is not going to work.
The only question here is whether it's important to simultaneously
support both DAC and MAC. As far as I can see, KaiGai is the only one
arguing that we don't need to do that (except for Tom, who doesn't
like either feature). If anyone else agrees with his position, now
would be a good time to speak up.
Peter made an excellent point a few emails upthread: there seemed to
be consensus in the September CommitFest that we needed SQL-level
support for row and column level security before we talked about
implementing those features as part of SELinux. I don't see that
we're any closer to that goal than we were then. There has been some
progress made on column-level permissions, but the patch is back in
"waiting for author" limbo, and the only alternatives for SQL-level
row-level permissions is to have them INSTEAD OF SELinux-based
row-level permissions. That's not the same thing at all, and I think
it's also the underlying reason behind Bruce's complaint here:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00863.php
...Robert