Re: Updates of SE-PostgreSQL 8.4devel patches (r1268) - Mailing list pgsql-hackers

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 <kaigai@kaigai.gr.jp>