Robert Haas wrote:
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.
The reason why I can never agree the simultaneous support both of
DAC and MAC is that it assumes we have one security system column
and one security field on HeapTupleHeader.
If we can agree the second approach (2 security system columns and
2 security features), I don't oppose to the simultaneous support.
However, again, the third approach give us too much pains much more
than its merits, so I can never agree. Giving up simultaneous support
is much better than compounding two values into one security field.
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.
Yes, I remember.
It is the reason why I also implemented the Row-level ACLs feature.
However, please remember the purpose of my 2 years activity is to
upstream the "fine-grained mandatory access controls with operating
syste collaboration", not a just "fine-grained (discretionary) access
controls".
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:
As I noted above, I don't oppose to simultaneous support both of
DAC and MAC, if we have *2 security system columns*.
If you can agrre this point, the next patch set will support them
simultaneously.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
